[devel] rpm 4.0.4-alt82

[devel] rpm 4.0.4-alt82

[Alexey Tourbin]

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. Ж(

Re: [devel] rpm 4.0.4-alt82

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 5219 bytes --]

On Mon, Dec 03, 2007 at 03:50:56PM +0300, Alexey Tourbin wrote:
[...]
> У меня предварительно готова новая сборка 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 их "оживляет"
> по мере необходимости.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] rpm 4.0.4-alt82

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2853 bytes --]

On Mon, Jan 14, 2008 at 10:00:45PM +0300, Dmitry V. Levin wrote:
> > Я пока воспринимаю ещё как экспериментальную.  Хотелось бы замутить
> > пересборку сизифа с 4.0.4-alt82 и потом проверить/обсудить, устраивает
> > ли нас новая схема зависимостей или нет.
> 
> Это ещё актуально?  Сейчас заканчивается очередная тестовая пересборка,
> можно попробовать.

Я думаю что там всё нормально, если только сама идея "цементировать"
или "наращивать" зависимости между подпакетами за счёт файловых
зависимостей не вызывает возражений.

Вот нетривиальный пример того, какой эффект даёт это "цементирование".

В пакете valgrind-devel-3.2.3-alt1.i586.rpm
имеется файл /usr/lib/pkgconfig/valgrind.pc
в котором имеется строка
Libs: -L${libdir}/valgrind/x86-linux -lcoregrind -lvex -lgcc

Здесь речь идёт о зависимостях на файлы
/usr/lib/valgrind/x86-linux/libcoregrind.a
/usr/lib/valgrind/x86-linux/libvex.a

Эти зависимости обнаруживаются с помощью pkgconfiglib.req.

Старый алгоритм поведения pkgconfiglib.req был такой:
поскольку эти файлы обнаружены под $RPM_BUILD_ROOT, то ничего не делать,
потому что как бы "внешнех зависимостей" нет.  Куда эти файлы будут
запакованы и будут ли они запакованы вообще, it's up to maintainer.

Новый алгоритм pkgconfiglib.req такой: ok, ставим файловую зависимость
на эти файлы, то есть
Requires: /usr/lib/valgrind/x86-linux/libcoregrind.a
Requires: /usr/lib/valgrind/x86-linux/libvex.a

Если эти файлы запакованы в тот же самый пакет, что и файл
/usr/lib/pkgconfig/valgrind.pc, то rpm оптимизирует (удалит)
эти Requires зависимости.  В противном случае зависимости останутся --
появляется требование, что эти файлы должны быть куда-то запакованы
(имеется в виду, что они должны быть запакованы в один из подпакетов,
на которые распилен пакет valgrind, но в точности передать имеено эту
семантику нельзя).

Правда в данном случае состоит в том, что файлы
/usr/lib/valgrind/x86-linux/libcoregrind.a
/usr/lib/valgrind/x86-linux/libvex.a
запакованы в другой пакет -- valgrind-tool-devel-3.2.3-alt1.i586.rpm.

То есть у пакета valgrind-devel появится косвенная зависимость на
valgrind-tool-devel, через файловые зависимости (которые можно понимать
почти что как обычные виртуальные зависимости).

Но пакет valgrind-tool-devel в свою очередь явно зависит от пакета
valgrind-devel (с точностью до = %version-%release).

Получается, что эффект "цементирования" как бы "нарушает" оригинальный
замысел maintainer'а отпилить два *-devel пакета.  С другой стороны,
этот оригинальный замысел допускает "прокол": можно установить пакет
valgrind-devel, но при этом нельзя слинковаться через valgrind.pc,
потому что не хватает соответствующих библиотек, которые были отпилены
в другой подпакет.  То есть "цементирование" теперь запрещает
незамкнутые зависимости между подпакетами.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] rpm 4.0.4-alt82

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

On Mon, Jan 14, 2008 at 10:56:15PM +0300, Alexey Tourbin wrote:
> On Mon, Jan 14, 2008 at 10:00:45PM +0300, Dmitry V. Levin wrote:
> > > Я пока воспринимаю ещё как экспериментальную.  Хотелось бы замутить
> > > пересборку сизифа с 4.0.4-alt82 и потом проверить/обсудить, устраивает
> > > ли нас новая схема зависимостей или нет.
> > 
> > Это ещё актуально?  Сейчас заканчивается очередная тестовая пересборка,
> > можно попробовать.
> 
> Я думаю что там всё нормально,

Только за это время обновился весь autocrap и rpm перестал собираться...


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] rpm 4.0.4-alt82

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

On Mon, Jan 14, 2008 at 11:26:29PM +0300, Dmitry V. Levin wrote:
> On Mon, Jan 14, 2008 at 10:56:15PM +0300, Alexey Tourbin wrote:
> > On Mon, Jan 14, 2008 at 10:00:45PM +0300, Dmitry V. Levin wrote:
> > > > Я пока воспринимаю ещё как экспериментальную.  Хотелось бы замутить
> > > > пересборку сизифа с 4.0.4-alt82 и потом проверить/обсудить, устраивает
> > > > ли нас новая схема зависимостей или нет.
> > > 
> > > Это ещё актуально?  Сейчас заканчивается очередная тестовая пересборка,
> > > можно попробовать.
> > 
> > Я думаю что там всё нормально,
> 
> Только за это время обновился весь autocrap и rpm перестал собираться...

Fixed.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]