[devel] rpm 4.0.4-alt87

[Stanislav Ievlev]

Может стоит отделить ALT-specific наработки в rpm в отдельный пакет? А то
теоретическая  миграция на 5.0 становится всё сложнее и сложнее.

On Sun, Feb 24, 2008 at 09:01:21PM +0300, Alexey Tourbin wrote:
> После некоторых колебаний я подготовил новую сборку rpm.
> 
>     4.0.4-alt87
>     
>     - implemented automatic dependencies for %%pre, %%preun, %%post,
>       and %%postun scriptlets (#7409)
>     - find-package: when possible, keep file-level dependencies as is,
>       without mapping them to package names
>     - find-package: relax file-level dependencies on unpackaged directories
>     - find-package: optimize out bulk dependencies on sh, cat, rm, mv etc.
>     - build/parseScript.c: optimize out RPMSENSE_INTERP dependencies on /bin/sh
>     - lib.req: enabled ELF_INTERP dependencies except for standard /lib/ld-linux.so.2
>     - functions (ValidateBuildRoot): require RPM_BUILD_ROOT path be canonical
> 
> Прокомментирую основные изменения:
> 
> 1) Поиск зависимостей в %post-скритпах.  Теперь зависимости 
> %post-скриптов вида Requires(post): ... можно не писать вручную (и лучше
> вообще не писать без особой нужды).  Реализация мне не очень нравится,
> но на практике это не должно повлиять на конечный результат (реализацию
> можно будет переделать, если станет понятно, как это можно сделать
> лучше).
> 
> Ранее я уже писал, что нужно понимать некоторые особенности работы
> shell.req, чтобы зависимости в шелл-коде %post-скриптов генерировались
> наиболее приемлемым образом.  В частности, если зависимости быть не
> должно (если она не строгая), то команды в шелл-коде нужно заворачивать
> в переменные:
> 
> 	x=/usr/bin/x
> 	if [ -x "$x" ]; then
> 		"$x"
> 	fi
> 
> В отличие от реализации jbj@ (в апстриме rpm), поиск зависимостей
> работает не только для shell-кода (например, если %post-скрипт написан
> на перле -- "%post -p /usr/bin/perl" -- то будет работать поиск перловых
> зависимостей).
> 
> 2) Когда путь к файлу указан явно, rpm теперь будет стараться сохранить
> зависимость на этот файл as is, без поиска соответствующего пакета,
> который содержит этот файл.  Это пока возможно не для всех путей (для
> некоторых путей это может дать "полу-анметы"), но для многих -- возможно.
> 
> Идея в том, что когда где-то требуется путь к файлу, то наиболее точный
> способ указать зависимость -- это просто вставить этот путь в
> зависимости.  Вот пример, когда это желательно.  Пусть в пакете
> используется /usr/bin/tclsh8.4.  Тогда старый rpm разрешал эту
> зависимость в пакет tcl (версии 8.4).  Новый пакет tcl (версии 8.5)
> уже не содержит файла /usr/bin/tclsh8.4, но зависимость на пакет tcl
> остаётся, естественно, удовлетворенной (то есть получаем нерабочий
> пакет).  После же пересборки старый rpm изменил бы зависимость
> s/tcl/tcl8.4/.  Всего этого можно избежать, если не делать "производных"
> зависимостей, а стараться указывать зависимости в их наиболее
> "первоначальном" виде.  Здесь имеется полная аналогия с виртуальными
> зависимостями -- они как раз предназначены для того, чтобы указывать
> зависимости в наиболее точном "первичном" виде.
> 
> Чтобы не появилось слишком много bulk зависимостей, я реализовал
> оптимизацию, которая удаляет следующие зависимости (как "команды"
> в шелл-скриптах, так и соответствующие им /bin/ пути):
> 	sh cat rm mv cp mkdir ln
> 
> (список можно будет немного увеличить, если кто-нибудь захочет
> составить более точную статистику, чем у меня получилось с ходу).
> 
> Поскольку сам rpm требует coreutils и /bin/sh, то в любой
> не окончательно поломанной среде эти зависимости должны быть
> заведомо удовлетворены.
> 
> Это изменение не затрагивает случая, когда известна только "команда"
> (из шелл-срипта) и поиск зависимости на эту команду идёт через перебор
> каталогов по default PATH.  Здесь осталось всё по-старому (как правило,
> генерируется зависимость на имя пакета, содержащего "команду").
> 
> 
> 2ldv: лучше собрать его два раза, второй раз --with-stuff.



> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel