On Thu, Sep 11, 2008 at 11:58:00PM +0400, Dmitry V. Levin wrote:
> > А как ведёт себя ld-linux.so, если путь из кеша даёт ENOENT?
> 
> Будет искать по файловой системе согласно /etc/ld.so.conf
> 
> > Такая ситуация может возникнуть при перекладывании библиотек между
> > /%_lib и %_libdir.  Если бы ENOENT считался как отсутствие в кеше,
> 
> Именно так.
> 
> > при котором запускается обычный поиск в каталогах, тогда можно было
> > бы откладывать вызов ldconfig до окончания транзакции.
> 
> Да, вызов ldconfig можно откладывать до окончания транзакции, если
> пренебречь одним обстоятельством, о котором идёт речь ниже.
> 
> > Кстати, возможно, имеет ли смысл использовать 'ldconfig -X'.
> > Перестановка симлинков (по отношению к rpm пакетам) -- очень
> > сомнительная фича (и она даёт проблему в %post_ldconfig при
> > даунгрейде библиотек).
> 
> Это объезд для пакетов, в которых забыли упаковать эти ссылки.

А есть ли такие пакеты?  Ведь lib.prov выставляет provides на soname
только в том случае, если имя файла/симлинка совпадает с названием
сонейма.

$ /usr/lib/rpm/lib.prov -vv /lib64/libglib-2.0.so.0*
lib.prov: processing /lib64/libglib-2.0.so.0
libglib-2.0.so.0()(64bit)
libglib-2.0.so.0(GLIB_2.8)(64bit)
libglib-2.0.so.0(GLIB_2.10)(64bit)
libglib-2.0.so.0(GLIB_2.12)(64bit)
libglib-2.0.so.0(GLIB_2.14)(64bit)
libglib-2.0.so.0(GLIB_2.15.6)(64bit)
lib.prov: processing /lib64/libglib-2.0.so.0.1600.5
$ 

Если бы мы забыли запаковать симлинк /lib64/libglib-2.0.so.0,
то бинарик /lib64/libglib-2.0.so.0.1600.5 не дал бы provides;
пакет, в котором забыли запаковать "значащий" симлинк, либо даст
анметы, либо просто этот сонейм никому не нужен (так что симлинк
можно и не делать).