[devel] rpm 4.0.4-alt82
Alexey Tourbin
=?iso-8859-1?q?at_=CE=C1_altlinux=2Eru?=
Пн Дек 3 15:50:56 MSK 2007
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. Ж(
Подробная информация о списке рассылки Devel