On Fri, Sep 12, 2008 at 12:16:43AM +0400, Alexey Tourbin wrote:
> 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
> только в том случае, если имя файла/симлинка совпадает с названием
> сонейма.

Этот объезд гораздо старше lib.prov

> $ /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;
> пакет, в котором забыли запаковать "значащий" симлинк, либо даст
> анметы, либо просто этот сонейм никому не нужен (так что симлинк
> можно и не делать).

OK, есть ещё какие-нибудь основания запускать ldconfig таким образом,
как это делается в пакетах сейчас?


-- 
ldv