[devel] %post-script prerequisites

[devel] %post-script prerequisites

[Alexey M. Tourbin]

Когда в %post-скрипте пакета запускается программа, запакованная
в сам этот пакет, тогда некоторые зависимости Requires пакета нужно
продублировать в Requires(post).  Например, если в пакете libgtk+2
запускается программа gkt-update-icon-cache, то должна появиться
зависимость на новый пакет glib2 вида
Requires(post): libglib-2.0.so.0(GLIB_2.18).

Update of /people/at/packages/rpm.git

Changes statistics since `4.0.4-alt95.M41.4-7-g3de7779' follows:
 scripts/find-scriptlet-requires.in |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)

Changelog since `4.0.4-alt95.M41.4-7-g3de7779' follows:
commit 555b366b2df864b37878a989ce337078555316a4
Author: Alexey Tourbin <at@altlinux>
Date:   Wed Sep 24 12:17:39 2008 +0000

    find-scriptlet-requires: describe Requires(post) problem in %post-scripts

Full diff since `4.0.4-alt95.M41.4-7-g3de7779' follows:
diff --git a/scripts/find-scriptlet-requires.in b/scripts/find-scriptlet-requires.in
index 85d432e..6d37605 100755
--- a/scripts/find-scriptlet-requires.in
+++ b/scripts/find-scriptlet-requires.in
@@ -77,4 +77,31 @@ RunMethods req "$methods" RunMethod
 PrintDeps >"$workdir"/deps0
 if [ -s "$workdir"/deps0 ]; then
 	cat "$workdir"/deps0
+else
+	exit
 fi
+
+# Consider a program which is packaged into a package, and which gets
+# called in %post or %preun scriptlet of the package (e.g. in libgtk+2,
+# gtk-update-icon-cache might be called in %post-script).  Packaged
+# programs have "Requires" dependencies, and, for %post and %preun scripts,
+# the dependencies on packaged programs are optimized out (as well as other
+# dependencies provided by the package).  This is a problem: when executing
+# %post-script, its prerequisites might not be installed yet (e.g.
+# gtk-update-icon-cache requires recent glib2 version installed/upgraded
+# before libgtk+2).
+
+# The solution is: 1) to detect all packaged programs (and files), recursively,
+# which are used in %post-script; and 2) to find prerequisites for such files
+# and programs (which are not provided by the package itself), and add them to
+# Requires(post) dependencies.  Also, we want to ensure that 3) the list of
+# Requires(post) additional dependencies is only a subset of original Requires.
+
+# The above applies only to %post and %preun scriptlets.
+case "${script##*/}" in
+	.post:* | .preun:* ) ;;
+	*) exit ;;
+esac
+
+# The above applies only if packaged programs can be used in scripts.
+[ -s "$RPM_BUILD_ROOT/.files:${RPM_SUBPACKAGE_NAME:?}" ] || exit 0

Re: [devel] %post-script prerequisites

[Dmitry V. Levin]

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

On Wed, Sep 24, 2008 at 12:37:26PM +0000, Alexey M. Tourbin wrote:
> Когда в %post-скрипте пакета запускается программа, запакованная
> в сам этот пакет, тогда некоторые зависимости Requires пакета нужно
> продублировать в Requires(post).  Например, если в пакете libgtk+2
> запускается программа gkt-update-icon-cache, то должна появиться
> зависимость на новый пакет glib2 вида
> Requires(post): libglib-2.0.so.0(GLIB_2.18).

Зачем должна появляться такая зависимость?


-- 
ldv

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

Re: [devel] %post-script prerequisites

[Alexey Tourbin]

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

On Wed, Sep 24, 2008 at 05:16:13PM +0400, Dmitry V. Levin wrote:
> On Wed, Sep 24, 2008 at 12:37:26PM +0000, Alexey M. Tourbin wrote:
> > Когда в %post-скрипте пакета запускается программа, запакованная
> > в сам этот пакет, тогда некоторые зависимости Requires пакета нужно
> > продублировать в Requires(post).  Например, если в пакете libgtk+2
> > запускается программа gkt-update-icon-cache, то должна появиться
> > зависимость на новый пакет glib2 вида
> > Requires(post): libglib-2.0.so.0(GLIB_2.18).
> 
> Зачем должна появляться такая зависимость?

1) пакет foo содержит программу /usr/bin/update-foo.
2) /usr/bin/update-foo запускается в %post-срипте пакета foo.
3) зависимость Requires(post): /usr/bin/update-foo естественным
образом оптимизируется (*), потому что на стадии выполнения %post-скрипта
файл /usr/bin/update-foo уже распакован (в любом случае, эта зависимость
ничего не дала бы).
4) файл /usr/bin/update-foo слинкован с libglib-2.0.so.0(GLIB_2.18).

Тогда rpm имеет право установить/обновить пакет glib2 после пакета foo.
Остается полагаться на топологическую сортировку пакетов при установке
или обновлении, но она может не сработать (rpm всё ещё имеет право
переупорядочить пакеты невыгодным нам образом), и тогда %post-скрипт
обломится.

Единственное решение состоит в том, что подмножество зависимостей
пакета foo, необходимых для запуска /usr/bin/update-foo (то есть,
в частности, libglib-2.0.so.0(GLIB_2.18)) необходимо дополнительно
указать в Requires(post).

[*] Правда есть ещё одно решение, которое только что мне пришло в
голову.  В пункте 3 можно не оптимизировать зависимость "Requires(post):
/usr/bin/update-foo"; тогда нужно модифицировать алгоритм топологической
сортировки пакетов следующим образом: если в пакете есть зависимость
Requires(post), которая разрешается в сам этот пакет, то все зависимости
Requires *должны* быть установлены до выполнения %post-скрипта (то есть
это неявная полная трансляция зависимостей Requires -> Requires(post),
вместо частичной и явной).

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

Re: [devel] %post-script prerequisites

[Dmitry V. Levin]

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

On Wed, Sep 24, 2008 at 03:43:54PM +0000, Alexey Tourbin wrote:
> On Wed, Sep 24, 2008 at 05:16:13PM +0400, Dmitry V. Levin wrote:
> > On Wed, Sep 24, 2008 at 12:37:26PM +0000, Alexey M. Tourbin wrote:
> > > Когда в %post-скрипте пакета запускается программа, запакованная
> > > в сам этот пакет, тогда некоторые зависимости Requires пакета нужно
> > > продублировать в Requires(post).  Например, если в пакете libgtk+2
> > > запускается программа gkt-update-icon-cache, то должна появиться
> > > зависимость на новый пакет glib2 вида
> > > Requires(post): libglib-2.0.so.0(GLIB_2.18).
> > 
> > Зачем должна появляться такая зависимость?
> 
> 1) пакет foo содержит программу /usr/bin/update-foo.
> 2) /usr/bin/update-foo запускается в %post-срипте пакета foo.
> 3) зависимость Requires(post): /usr/bin/update-foo естественным
> образом оптимизируется (*), потому что на стадии выполнения %post-скрипта
> файл /usr/bin/update-foo уже распакован (в любом случае, эта зависимость
> ничего не дала бы).
> 4) файл /usr/bin/update-foo слинкован с libglib-2.0.so.0(GLIB_2.18).
> 
> Тогда rpm имеет право установить/обновить пакет glib2 после пакета foo.
> Остается полагаться на топологическую сортировку пакетов при установке
> или обновлении, но она может не сработать (rpm всё ещё имеет право
> переупорядочить пакеты невыгодным нам образом), и тогда %post-скрипт
> обломится.

rpm пытается упорядочить установку пакетов согласно зависимостям.
Невыгодное упорядочение может возникнуть только в случае, если имеет
место цикл зависимостей, который был разорван неудачно.  Насколько
это реально, в применении к описываемой ситуации с %post-скриптом?


-- 
ldv

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

Re: [devel] %post-script prerequisites

[Alexey Tourbin]

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

On Wed, Sep 24, 2008 at 11:28:41PM +0400, Dmitry V. Levin wrote:
> > 1) пакет foo содержит программу /usr/bin/update-foo.
> > 2) /usr/bin/update-foo запускается в %post-срипте пакета foo.
> > 3) зависимость Requires(post): /usr/bin/update-foo естественным
> > образом оптимизируется (*), потому что на стадии выполнения %post-скрипта
> > файл /usr/bin/update-foo уже распакован (в любом случае, эта зависимость
> > ничего не дала бы).
> > 4) файл /usr/bin/update-foo слинкован с libglib-2.0.so.0(GLIB_2.18).
> > 
> > Тогда rpm имеет право установить/обновить пакет glib2 после пакета foo.
> > Остается полагаться на топологическую сортировку пакетов при установке
> > или обновлении, но она может не сработать (rpm всё ещё имеет право
> > переупорядочить пакеты невыгодным нам образом), и тогда %post-скрипт
> > обломится.
> 
> rpm пытается упорядочить установку пакетов согласно зависимостям.
> Невыгодное упорядочение может возникнуть только в случае, если имеет
> место цикл зависимостей, который был разорван неудачно.  Насколько
> это реально, в применении к описываемой ситуации с %post-скриптом?

На практике дублирование зависимостей Requires(post), скорее всего,
ничего не даст, кроме *гарантии*, что упорядочение всегда будет
правильным.  Но как раз нужна именно гарантия, иначе можно договориться
до того, что на практике зависимости Requires(pre) и Requires(post)
вообще не нужны.

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

Re: [devel] %post-script prerequisites

[Alexey Tourbin]

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

On Wed, Sep 24, 2008 at 11:28:41PM +0400, Dmitry V. Levin wrote:
> On Wed, Sep 24, 2008 at 03:43:54PM +0000, Alexey Tourbin wrote:
> > Тогда rpm имеет право установить/обновить пакет glib2 после пакета foo.
> > Остается полагаться на топологическую сортировку пакетов при установке
> > или обновлении, но она может не сработать (rpm всё ещё имеет право
> > переупорядочить пакеты невыгодным нам образом), и тогда %post-скрипт
> > обломится.
> 
> rpm пытается упорядочить установку пакетов согласно зависимостям.
> Невыгодное упорядочение может возникнуть только в случае, если имеет
> место цикл зависимостей, который был разорван неудачно.  Насколько
> это реально, в применении к описываемой ситуации с %post-скриптом?

Между прочим, я обратил внимание на эту проблему, когда взялся готовить
новую версию libgtk+2.

[at@people ~]$ rpmpeek /ALT/Sisyphus/files/SRPMS/libgtk+2-2.12.11-alt2.src.rpm cat -n libgtk2.spec |grep -C1 glib
    61
    62  %define glib_ver 2.13.5
    63  %define cairo_ver 1.%api_ver
--  
    71  # We need to prereq these so we can run gtk-query-immodules-%api_ver in post
    72  PreReq: glib2 >= %glib_ver
    73  PreReq: libpango >= %pango_ver
--  
    78
    79  BuildPreReq: glib2-devel >= %glib_ver
    80  BuildPreReq: libcairo-devel >= %cairo_ver
[at@people ~]$ 

Комментарий насчёт "We need to prereq" по сути правильный -- это именно
тот класс проблем, который следовало бы разрешать автоматически, а не
вручную.

С другой стороны, обращает на себя внимание различие между минимальной
версией glib2, необходимой для сборки, и минимальной версией glib2,
необходимой впоследствии для установки.

Для сборки требуется далеко не самая свежая версия glib2, так что
сборочную зависимость с версией можно было бы вообще не указывать (в
configure.in, действительно, указана версия 2.13.5, а в branch 4.0
сейчас лежит версия 2.14.1, так что сборочная зависимость с версией
просто не актуальна).

Но установочная зависимость может быть гораздо больше минимальной
сборочной зависимости, потому что при сборке с более свежей версией будут
использоваться новые функции glib2 -- так, при сборке со свежей версией
glib2 должна появиться зависимость на libglib-2.0.so.0(GLIB_2.18).

Значит, зависимость вида "PreReq: glib2 >= %glib_ver" симптоматична:
она добавлена из правильного соображения, но по сути оказывается
недостаточной.  На самом деле вместо "топорной" PreReq зависимости
на уровне версии нужна "бинарная" зависимость вида Requires(post)
на уровне ABI.

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

Re: [devel] %post-script prerequisites

[Alexey Tourbin]

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

On Thu, Sep 25, 2008 at 06:19:14AM +0000, Alexey Tourbin wrote:
> On Wed, Sep 24, 2008 at 11:28:41PM +0400, Dmitry V. Levin wrote:
> > > 1) пакет foo содержит программу /usr/bin/update-foo.
> > > 2) /usr/bin/update-foo запускается в %post-срипте пакета foo.
> > > 3) зависимость Requires(post): /usr/bin/update-foo естественным
> > > образом оптимизируется (*), потому что на стадии выполнения %post-скрипта
> > > файл /usr/bin/update-foo уже распакован (в любом случае, эта зависимость
> > > ничего не дала бы).
> > > 4) файл /usr/bin/update-foo слинкован с libglib-2.0.so.0(GLIB_2.18).
> > > 
> > > Тогда rpm имеет право установить/обновить пакет glib2 после пакета foo.
> > > Остается полагаться на топологическую сортировку пакетов при установке
> > > или обновлении, но она может не сработать (rpm всё ещё имеет право
> > > переупорядочить пакеты невыгодным нам образом), и тогда %post-скрипт
> > > обломится.
> > 
> > rpm пытается упорядочить установку пакетов согласно зависимостям.
> > Невыгодное упорядочение может возникнуть только в случае, если имеет
> > место цикл зависимостей, который был разорван неудачно.  Насколько
> > это реально, в применении к описываемой ситуации с %post-скриптом?
> 
> На практике дублирование зависимостей Requires(post), скорее всего,
> ничего не даст, кроме *гарантии*, что упорядочение всегда будет
> правильным.  Но как раз нужна именно гарантия, иначе можно договориться
> до того, что на практике зависимости Requires(pre) и Requires(post)
> вообще не нужны.

4.0.4-alt95.M41.4-14-g9b2294d

Пересборка пакета postfix.

$ grep -C1 find-scriptlet-requires: log2
+ /usr/lib/rpm/find-scriptlet-requires /usr/src/tmp/postfix-buildroot/.post:postfix
find-scriptlet-requires: self-packaged files used in this scriptlet: /etc/chroot.d/postfix.all /etc/postfix/post-install /etc/rc.d/init.d/postfix
find-scriptlet-requires: more self-packaged files: /etc/chroot.d/postfix.conf /etc/chroot.d/postfix.lib /usr/lib64/libpostfix-2.4.9.so /usr/lib64/libpostfix_dict-2.4.9.so /usr/sbin/postmap
find-scriptlet-requires: additional dependencies for self-packaged files: /etc/chroot.d /etc/chroot.d(Fatal) /etc/chroot.d(copy_resolv_conf) /etc/chroot.d(copy_resolv_lib) /etc/chroot.d/functions /etc/rc.d/init.d(SourceIfNotEmpty) /etc/rc.d/init.d(action) /etc/rc.d/init.d(failure) /etc/rc.d/init.d(is_yes) /etc/rc.d/init.d(msg_usage) /etc/rc.d/init.d(status) /etc/rc.d/init.d(success) /etc/rc.d/init.d/functions /lib64/ld-linux-x86-64.so.2 /usr/bin/newaliases ed findutils glibc-utils grep libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.2)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) libcdb.so.1()(64bit) libdb-4.7.so()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit) libnsl.so.1(GLIBC_2.2.5)(64bit) libresolv.so.2(GLIBC_2.2.5)(64bit) rtld(GNU_HASH) sed
+ exit 0
--
+ /usr/lib/rpm/find-scriptlet-requires /usr/src/tmp/postfix-buildroot/.preun:postfix
find-scriptlet-requires: self-packaged files used in this scriptlet: /etc/rc.d/init.d/postfix
find-scriptlet-requires: additional dependencies for self-packaged files: /etc/rc.d/init.d(SourceIfNotEmpty) /etc/rc.d/init.d(action) /etc/rc.d/init.d(failure) /etc/rc.d/init.d(is_yes) /etc/rc.d/init.d(msg_usage) /etc/rc.d/init.d(status) /etc/rc.d/init.d(success) /etc/rc.d/init.d/functions glibc-utils
+ exit 0
$

$ sh -c '. buildlog.sh ; buildlog_deps $1' -c log1 >.1
$ sh -c '. buildlog.sh ; buildlog_deps $1' -c log2 >.2
$ diff -U1 .1 .2
--- .1	2008-10-05 19:12:20 +0400
+++ .2	2008-10-05 19:12:23 +0400
@@ -14,2 +14,3 @@
 postfix-2.4.9-alt1	Provides	smtpdaemon
+postfix-2.4.9-alt1	Requires	/bin/sh
 postfix-2.4.9-alt1	Requires	/etc/chroot.d
@@ -32,2 +33,3 @@
 postfix-2.4.9-alt1	Requires	/usr/bin/perl
+postfix-2.4.9-alt1	Requires	coreutils
 postfix-2.4.9-alt1	Requires	diffutils
@@ -56,4 +58,19 @@
 postfix-2.4.9-alt1	Requires(post)	/bin/sh
+postfix-2.4.9-alt1	Requires(post)	/etc/chroot.d
+postfix-2.4.9-alt1	Requires(post)	/etc/chroot.d(Fatal)
+postfix-2.4.9-alt1	Requires(post)	/etc/chroot.d(copy_resolv_conf)
+postfix-2.4.9-alt1	Requires(post)	/etc/chroot.d(copy_resolv_lib)
+postfix-2.4.9-alt1	Requires(post)	/etc/chroot.d/functions
+postfix-2.4.9-alt1	Requires(post)	/etc/rc.d/init.d(SourceIfNotEmpty)
+postfix-2.4.9-alt1	Requires(post)	/etc/rc.d/init.d(action)
+postfix-2.4.9-alt1	Requires(post)	/etc/rc.d/init.d(failure)
+postfix-2.4.9-alt1	Requires(post)	/etc/rc.d/init.d(is_yes)
+postfix-2.4.9-alt1	Requires(post)	/etc/rc.d/init.d(msg_usage)
+postfix-2.4.9-alt1	Requires(post)	/etc/rc.d/init.d(status)
+postfix-2.4.9-alt1	Requires(post)	/etc/rc.d/init.d(success)
+postfix-2.4.9-alt1	Requires(post)	/etc/rc.d/init.d/functions
+postfix-2.4.9-alt1	Requires(post)	/lib64/ld-linux-x86-64.so.2
 postfix-2.4.9-alt1	Requires(post)	/sbin/chkconfig
 postfix-2.4.9-alt1	Requires(post)	/sbin/ldconfig
+postfix-2.4.9-alt1	Requires(post)	/usr/bin/newaliases
 postfix-2.4.9-alt1	Requires(post)	/usr/sbin/control
@@ -61,2 +78,18 @@
 postfix-2.4.9-alt1	Requires(post)	coreutils
+postfix-2.4.9-alt1	Requires(post)	ed
+postfix-2.4.9-alt1	Requires(post)	findutils
+postfix-2.4.9-alt1	Requires(post)	glibc-utils
+postfix-2.4.9-alt1	Requires(post)	grep
+postfix-2.4.9-alt1	Requires(post)	libc.so.6(GLIBC_2.2.5)(64bit)
+postfix-2.4.9-alt1	Requires(post)	libc.so.6(GLIBC_2.3)(64bit)
+postfix-2.4.9-alt1	Requires(post)	libc.so.6(GLIBC_2.3.2)(64bit)
+postfix-2.4.9-alt1	Requires(post)	libc.so.6(GLIBC_2.3.4)(64bit)
+postfix-2.4.9-alt1	Requires(post)	libc.so.6(GLIBC_2.4)(64bit)
+postfix-2.4.9-alt1	Requires(post)	libcdb.so.1()(64bit)
+postfix-2.4.9-alt1	Requires(post)	libdb-4.7.so()(64bit)
+postfix-2.4.9-alt1	Requires(post)	libdl.so.2(GLIBC_2.2.5)(64bit)
+postfix-2.4.9-alt1	Requires(post)	libnsl.so.1(GLIBC_2.2.5)(64bit)
+postfix-2.4.9-alt1	Requires(post)	libresolv.so.2(GLIBC_2.2.5)(64bit)
+postfix-2.4.9-alt1	Requires(post)	rtld(GNU_HASH)
+postfix-2.4.9-alt1	Requires(post)	sed
 postfix-2.4.9-alt1	Requires(postun)	/sbin/postun_ldconfig
@@ -69,4 +102,13 @@
 postfix-2.4.9-alt1	Requires(preun)	/bin/sh
+postfix-2.4.9-alt1	Requires(preun)	/etc/rc.d/init.d(SourceIfNotEmpty)
+postfix-2.4.9-alt1	Requires(preun)	/etc/rc.d/init.d(action)
+postfix-2.4.9-alt1	Requires(preun)	/etc/rc.d/init.d(failure)
+postfix-2.4.9-alt1	Requires(preun)	/etc/rc.d/init.d(is_yes)
+postfix-2.4.9-alt1	Requires(preun)	/etc/rc.d/init.d(msg_usage)
+postfix-2.4.9-alt1	Requires(preun)	/etc/rc.d/init.d(status)
+postfix-2.4.9-alt1	Requires(preun)	/etc/rc.d/init.d(success)
+postfix-2.4.9-alt1	Requires(preun)	/etc/rc.d/init.d/functions
 postfix-2.4.9-alt1	Requires(preun)	/sbin/chkconfig
 postfix-2.4.9-alt1	Requires(preun)	coreutils
+postfix-2.4.9-alt1	Requires(preun)	glibc-utils
 postfix-2.4.9-alt1	Requires(rpmlib)	rpmlib(CompressedFileNames) <= 3.0.4-1

Бинарные зависимости появляются из-за /usr/sbin/postmap, который
слинкован с libpostfix и libpostfix_dict, так что даже появляется
зависимость Requires(post) на libdb-4.7.so.  Выглядит чудно,
но вроде правильно.

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

Re: [devel] %post-script prerequisites

[Alexey Tourbin]

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

On Sun, Oct 05, 2008 at 07:20:00PM +0400, Alexey Tourbin wrote:
> @@ -56,4 +58,19 @@
>  postfix-2.4.9-alt1	Requires(post)	/bin/sh
> +postfix-2.4.9-alt1	Requires(post)	/etc/chroot.d
> +postfix-2.4.9-alt1	Requires(post)	/etc/chroot.d(Fatal)
> +postfix-2.4.9-alt1	Requires(post)	/etc/chroot.d(copy_resolv_conf)
> +postfix-2.4.9-alt1	Requires(post)	/etc/chroot.d(copy_resolv_lib)
> +postfix-2.4.9-alt1	Requires(post)	/etc/chroot.d/functions
> +postfix-2.4.9-alt1	Requires(post)	/etc/rc.d/init.d(SourceIfNotEmpty)
> +postfix-2.4.9-alt1	Requires(post)	/etc/rc.d/init.d(action)
> +postfix-2.4.9-alt1	Requires(post)	/etc/rc.d/init.d(failure)
> +postfix-2.4.9-alt1	Requires(post)	/etc/rc.d/init.d(is_yes)
> +postfix-2.4.9-alt1	Requires(post)	/etc/rc.d/init.d(msg_usage)
> +postfix-2.4.9-alt1	Requires(post)	/etc/rc.d/init.d(status)
> +postfix-2.4.9-alt1	Requires(post)	/etc/rc.d/init.d(success)
> +postfix-2.4.9-alt1	Requires(post)	/etc/rc.d/init.d/functions
> +postfix-2.4.9-alt1	Requires(post)	/lib64/ld-linux-x86-64.so.2
>  postfix-2.4.9-alt1	Requires(post)	/sbin/chkconfig
>  postfix-2.4.9-alt1	Requires(post)	/sbin/ldconfig
> +postfix-2.4.9-alt1	Requires(post)	/usr/bin/newaliases
>  postfix-2.4.9-alt1	Requires(post)	/usr/sbin/control
> @@ -61,2 +78,18 @@
>  postfix-2.4.9-alt1	Requires(post)	coreutils
> +postfix-2.4.9-alt1	Requires(post)	ed
> +postfix-2.4.9-alt1	Requires(post)	findutils
> +postfix-2.4.9-alt1	Requires(post)	glibc-utils
> +postfix-2.4.9-alt1	Requires(post)	grep
> +postfix-2.4.9-alt1	Requires(post)	libc.so.6(GLIBC_2.2.5)(64bit)
> +postfix-2.4.9-alt1	Requires(post)	libc.so.6(GLIBC_2.3)(64bit)
> +postfix-2.4.9-alt1	Requires(post)	libc.so.6(GLIBC_2.3.2)(64bit)
> +postfix-2.4.9-alt1	Requires(post)	libc.so.6(GLIBC_2.3.4)(64bit)
> +postfix-2.4.9-alt1	Requires(post)	libc.so.6(GLIBC_2.4)(64bit)
> +postfix-2.4.9-alt1	Requires(post)	libcdb.so.1()(64bit)
> +postfix-2.4.9-alt1	Requires(post)	libdb-4.7.so()(64bit)
> +postfix-2.4.9-alt1	Requires(post)	libdl.so.2(GLIBC_2.2.5)(64bit)
> +postfix-2.4.9-alt1	Requires(post)	libnsl.so.1(GLIBC_2.2.5)(64bit)
> +postfix-2.4.9-alt1	Requires(post)	libresolv.so.2(GLIBC_2.2.5)(64bit)
> +postfix-2.4.9-alt1	Requires(post)	rtld(GNU_HASH)
> +postfix-2.4.9-alt1	Requires(post)	sed
>  postfix-2.4.9-alt1	Requires(postun)	/sbin/postun_ldconfig

> Бинарные зависимости появляются из-за /usr/sbin/postmap, который
> слинкован с libpostfix и libpostfix_dict, так что даже появляется
> зависимость Requires(post) на libdb-4.7.so.  Выглядит чудно,
> но вроде правильно.

К сожалению, во многих других (типичных) случаях обнаружить файловые
зависимости гораздо сложнее.  Например, из кода "/usr/sbin/post_service foo"
сейчас никак нельзя вывести требование не файл "/etc/rc.d/init.d/foo".
И, значит, никак нельзя добавить Requires(post) зависимости, которые
соответствовали бы потребностям /etc/rc.d/init.d/foo.

А файл /etc/rc.d/init.d/foo в свою очередь содержит ещё одну обёртку:
как правило, демон запускается через start_daemon.  Так что из скрипта
/etc/rc.d/init.d/foo не удастся просто так извлечь зависимость на
бинарик демона.  А если бы мы извлекли зависимость на этот бинарик,
тогда все бинарные зависимости этого бинарика продублировались бы в
Requires(post).  Тогда это получается ближе ко второму сценирю: если
обнаруживается, что в %post-скритпе вызывается какая либо программа,
запакованная в том же самом пакете, тогда *все* Requires зависимости
пакета неоходимо продублирова (точнее, как бы "сдвинуть") на
Requires(post).

Но, опять же, нельзя достаточно надёжно засечь, дёргается ли
в %post-скрипте какая-либо запакованная программа или нет.

Что-то я прямо не знаю что делать.  С одной стороны, реализован
правильный механизм, который в принципе может работать.  С другой
стороны, он не будет работать в типичных (унифицированных) случаях.
А если бы он хорошо работал во всех случаях, тогда бы мы получили
простое дублирование ("сдвиг") зависимостей Requires -> Requires(post).

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