[devel] A: Меры по синхронизации версии libdb в libaprutil1, apache2 и его внешних модулях (was: libdb-4.6.so users)

Aleksey Avdeev =?iso-8859-1?q?solo_=CE=C1_solin=2Espb=2Eru?=
Ср Окт 29 23:45:54 MSK 2008


Boris Savelev пишет:
>>> Я не особо понимаю как?.. что-то при сборке апача линкуется с libdb?
>>  Да. Причём -- именно с libdb4.4 (т. к. именно её использование задано в
>> спеке). И сторонние модули тоже привязываются к версии libdb с которой
>> собран apache2. Если данные версии разъезжаются велик шанс
>> неработоспособности apache2 или таких модулей.
>>
> Не могу найти.
> /var/ftp/pub/ALTLinux/Sisyphus/i586/RPMS.classic
> 
> rpm -Rp apache2-*.rpm | grep libdb
> apache2-libdb = 4.4
> rpm-macros-apache2-libdb = 4.4
> apache2-libdb = 4.4
> apache2-libdb = 4.4
> apache2-libdb = 4.4
> apache2-libdb = 4.4
> apache2-libdb = 4.4
> apache2-libdb = 4.4
> apache2-libdb = 4.4
> 
> Все эти зависимости проставлены руками.

   Похоже это результат работы оптимизатора зависимостей...

> Какой конкретно модуль апача, или еще что-нибудь слинкован с libdb?

   Непосредственно сам демон:

$ ldd /usr/sbin/httpd2.prefork
         libpcre.so.3 => /lib64/libpcre.so.3 (0x00002b0ad5583000)
         libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0 
(0x00002b0ad57a5000)
         libapr-1.so.0 => /usr/lib64/libapr-1.so.0 (0x00002b0ad59c7000)
         libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b0ad5bf2000)
         libc.so.6 => /lib64/libc.so.6 (0x00002b0ad5e0c000)
         libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002b0ad6147000)
         libdb-4.7.so => /lib64/libdb-4.7.so (0x00002b0ad6380000)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00002b0ad66bf000)
         libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b0ad68e2000)
         libdl.so.2 => /lib64/libdl.so.2 (0x00002b0ad6ae6000)
         /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)

   Причём, похоже, линкуется данный зараза с той libdb, с которой 
слинкована libaprutil-1.so...

   В общем нам надо применять противограбливые меры. Предлагаю следующие:

1. Версию используемой libdb фиксировать в спеке aprutil1 явным образом. 
Причём:

а) Для сборки в Сизиф использовать наиболее свежую libdb. Или, если 
будут противопоказания со стороны пользователей libaprutil1 (например 
subversion -- насколько знаю там не все libdb одинаково полезны) -- 
наиболее свежую из допустимых.

б) Для сборок в дистрибутивы/бранчи использовать ту версию libdb с 
которой сборка выполнялась ранее, без оглядки на появление там более 
свежих libdb. (Переход на другую libdb там возможен, но причина должна 
быть достаточно серьёзной.)

2. Обеспечить запрет установки пакетов использующих libaprutil1 (и, 
возможно libdb), если системная libaprutil1 собрана с другой версией libdb.

   П. 1 можно обеспечить кодом примерно соответствующим коду выбора 
libdb4-devel в зависимости от дистрибутива/бранча и/или libdb выбранного 
явно rpm-macros-apache2 (см. 
<http://git.altlinux.org/people/solo/packages/?p=rpm-macros-apache2.git;a=blob;f=rpm-macros-apache2.spec;h=1a349243332706ef1e5e4d0cd7832bef132f17f4;hb=70ecd16d1568bd1ada31428a5d002b146df3d4db>) 
и макросом возвращающим версию libdb в зависимости от вывода 
apu-1-config --libs.

   П. 2 -- ручным Provides/Requires libaprutil1-libdb = <версия libdb> 
(по типу apache2-libdb = <версия libdb>, используемого в apache2 и его 
модулях).

PS: Могу подготовить и залить в Daedalus aprutil1 с подобными изменениями.

-- 

С уважением. Алексей.


----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 552 байтов
Описание: OpenPGP digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20081029/104afcda/attachment.bin>


Подробная информация о списке рассылки Devel