From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 3 Dec 2007 15:50:56 +0300 From: Alexey Tourbin To: devel@lists.altlinux.org Message-ID: <20071203125056.GD361@solemn.turbinal> Mail-Followup-To: devel@lists.altlinux.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit Subject: [devel] rpm 4.0.4-alt82 X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2007 12:50:59 -0000 Archived-At: List-Archive: List-Post: On Tue, Nov 27, 2007 at 06:31:18PM +0300, Alexey Tourbin wrote: > В общем, у меня сейчас есть идея включить поиск всех симлинков > на межпакетные зависимости. Это защищает от неупаковки таргетов. > Т.е. проверка типа [ -e "$RPM_BUILD_ROOT$f" ] это такая лавочка, > что файл вроде бы должен "где-то" быть, но нет никакой гарантии, > что его потом вообще куда-нибудь запакуют. Эту лавочку желательно > закрыть. Будут появляться зависимости на файлы, и rpm сможет > оптимизировать/удалить эти зависимости в пределах одного подпакета > (речь идёт о подходе который реализован в 4.0.4-alt81-6-g6e73a89). > С другой стороны, это как минимум означает, что у каждого lib*-devel > пакета из-за симлнка /usr/lib/lib*.so -> /usr/lib/lib*.so.X.Y появится > "файловая" зависимость на /usr/lib/lib*.so.X.Y. > > То есть, с одной стороны, дополнительные зависимости между > подпакетами защищают от ошибок упаковки. С другой стороны, если всё > упаковано правильно, то дополнительные виртуальные зависимости > становятся излишними и их можно каким-то образом оптимизировать. > Сейчас есть возможность начать делать первую часть (ставить > дополнительные виртуальные зависимости), но пока нет хорошей идеи > как делать вторую часть (удалять совпадающие виртуальные зависимости > при жесткой связи между подпакетами). > > С третьей стороны, полная оптимизация совпадающих зависимостей > при жесткой связи между подпакетами -- для меня это ломка стереотипов. > То есть если rpm перестанет явно зависеть от librpm-4.0.4.so (вследствие > жесткой зависимости на librpm = %version-%release) то мне придётся > к этому какое-то время привыкать. То есть это очень сильная > оптимизация, которая сейчас может противоречить привычной интуиции. У меня предварительно готова новая сборка rpm 4.0.4-alt82. Я пока воспринимаю ещё как экспериментальную. Хотелось бы замутить пересборку сизифа с 4.0.4-alt82 и потом проверить/обсудить, устраивает ли нас новая схема зависимостей или нет. 4.0.4-alt82 - reqprov.c (addReqProv): implemented optimization of "self-requires" dependencies on packaged files - find-package, shell.req, pkgconfiglib.req, symlinks.req: do not completely ignore dependencies on files which are under RPM_BUILD_ROOT; that is, emit "file-level" dependencies which will be optimized out by addReqProv() within a single subpackage, but will protect from unpackaged files between subpackages; works best with apt-utils >= 0.5.15lorg2-alt17 - lib.req: try to emit file-level dependencies instead of "soname-level" dependencies on private libraries (see git log for details); this can largely reduce the need for %%add_findprov_lib_path which is "public provides for private libraries" Здесь два существенных изменения. Во-первых, будут проставляться все файловые зависимости на файлы которые обнаруживаются под RPM_BUILD_ROOT. Раньше зависимости такого рода просто игнорировались -- считалось, что maintainer должен запаковать всё что нужно и при этом правильно расставить зависимости между подпакетами. Теперь эта "лавочка" прикрывается. В пределах одного ПОДПАКЕТА все файловые зависимости будут оптимизироваться (удаляться). Но теперь появится много зависимостей которые актуальны для связей между РАЗНЫМИ подпакетами (собранными из одного исходного пакета). Например, у librpm-devel (если собрать его два раза) теперь зависимости изменятся так: $ compare_packages -a -R -- ~sisyphus/files/i586/RPMS/librpm-devel-4.0.4-alt81.i586.rpm -- librpm-devel-4.0.4-alt82.athlon.rpm --- /tmp/.private/at/compare_packages.IlbTPR4179/1 2007-12-03 15:32:59 +0300 +++ /tmp/.private/at/compare_packages.IlbTPR4179/2 2007-12-03 15:32:59 +0300 @@ -1,9 +1,13 @@ +/usr/lib/librpm-4.0.4.so +/usr/lib/librpmbuild-4.0.4.so +/usr/lib/librpmdb-4.0.4.so +/usr/lib/librpmio-4.0.4.so bzlib-devel libbeecrypt-devel libdb4.4-devel libpopt-devel -librpm = 4.0.4-alt81 -librpmbuild = 4.0.4-alt81 +librpm = 4.0.4-alt82 +librpmbuild = 4.0.4-alt82 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 $ Добавившиеся зависимости означают что пакет librpm-devel "не может жить" без файлов /usr/lib/librpm-4.0.4.so и т.д. (потому что там есть симлинки для линковки которые показывают на эти файлы). Но этих файлов нет в самом пакете librpm-devel, поэтому кто-то их должен "предоставлять" (на самом деле явного provides не требуется, apt будет хорошо разрешать файловые зависимости начиная с alt17). На практике эти файлы должен содержать какой-то другой подпакет, собранный из этого же исходного пакета (хотя сейчас нет способа передать при помощи зависимости именно этот строгий смысл). То есть, с одной стороны, как я уже писал, появляется много "лишних" на первый взгляд зависимостей. С другой стороны, эта зависимости защищают от ошибок неупаковки файлов между подпакетами. Далее можно будет реализовать оптимизацию виртуальных зависимостей при жесткой связи между подпакетами (= %version-%release). Но это не очень хорошо вписывается в архитектуру rpm, и, кроме того, слишком сильная "очистка" виртуальных зависимостей между подпакетами может противоречить интуиции maintainer'а. Второе изменение на практике сводится к тому, что в openoffice.org теперь можно будет отключить %add_findprov_lib_path, чтобы он не предоставлял несколько сотен "приватных" виртуальных библиотек. При этом зависимости между подпакетами openoffice.org-kde и -gnome будут сведены к зависимостям на файлы, то есть вместо зависимостей типа $ rpm -qpR openoffice.org-kde-2.3.0-alt6.i586.rpm |grep /usr/lib ... /usr/lib/OpenOffice.org2/program/libcomphelp4gcc3.so ... /usr/lib/OpenOffice.org2/program/libpsp680li.so(LIBPSPRINT_1_0) ... $ будут "чисто файловые" зависимости /usr/lib/OpenOffice.org2/program/libcomphelp4gcc3.so /usr/lib/OpenOffice.org2/program/libpsp680li.so Это "ослабление" в основном не должно нарушить какой-то бинарной совместимости, поскольку эта "замена сонеймов (со скобками) на файлы" происходит только для подпакетов в пределах одного исходного пакета, а такие подпакеты, как правильно, должны иметь жесткую связь. Идея тут в том, что "сонеймы со скобками" нужно явно предоставлять через provides (что в случае с openoffice.org заметно засоряет базу зависимостей), а "файлы" явно предоставлять не нужно, apt их "оживляет" по мере необходимости. PS: у меня истёк gpg-ключ 0x38E7BB46. Ж(