[devel] A: Меры по синхронизации версии libdb в libaprutil1, apache2 и его внешних модулях

[Aleksey Avdeev]

Dmitry Afanasov пишет:
> 31.10.08, Aleksey Avdeev<solo на solin.spb.ru> написал(а):
>>   Привязку к libaprutil1 собранной с нужной libdb лучше сделать сейчас:
>> Иначе придётся тратить время на разбор ситуаций типа той что я приводил...
>>
>>   Я могу сделать это, и залить в git/Daedalus...
> как будет - обязательно посмотрю.
> 
> 
> на предмет "попозже": я не совсем пока понимаю, как происходят завязки
> на libapr и libaprutil. знаю точно, что используется libdb и её версия
> берется из %apu_config (apr-1-config на моей машине).

   Не apr-1-config, а из apu-1-config:

$ apr-1-config --libs

$ apu-1-config --libs
  -lldap -llber -ldb-4.7 -lexpat

> 
> для обеспечения совпадения версии libdb и libaprutil1 достаточно в
> buildreq прописать libaprutil1-devel и проследить, чтобы configure
> продолжал выдирать версию из %apu_config.

   Да.

> 
> но здесь речь не только о libdb - subversion зачем-то ещё нужны эти
> apr'ы, наерное не только для определения libdb. этого я пока не знаю:
> не было нужды смотреть.
> 
> в итоге: для определения версии libdb я сохраню текущее состояние - из
> libaprutil.

   Текущее, но только на момент сборки. После инсталляции ситуация 
установки libaprutil1 собранной с другой libdb сейчас никак не 
отслеживается... А на мой взгляд -- надо.

> 
> для обеспечения же зависимости именно на libapr/libaprutil я пока не
> знаю что делать, и надо ли это subversion. этот механизм я буду
> рассматривать позже, как разберусь, на кой ляд они вообще нужны :)

   Судя потому что присутствуют библиотеки одновременно слинкованные с 
libdb4.x и с libaprutil-1, которая в свою очередь может быть слинкована 
с libdb4.y -- такую ситуацию отслеживать надо. По крайней мере до 
получения полной ясности что такая ситуация ничему не мешает (сейчас её 
нет).

> 
>>> subversion для сборки требует libapr, не libaprutil1. использует
>>> обоих. я пока не понял - критично это или нет :)
>>   Не может быть, т. к.:
>> [...]
> прошу прощения, я ошибся. не заметил, что строка BuildPreReq:
> %apu_name-devel >= %apu_ver не в какие %if_with не входит.
> 
> в итоге имеем, что subversion для сборки требует и libapr1-devel и
> libaprutil1-devel. оба прописаны в buildreq.
> для установки требует:
> libsubversion - только libapr1

   Нет. Смотрю текущий libsubversion-1.4.4-alt2.3:

$ rpm -ql libsubversion|xargs readelf -d |fgrep libaprutil
  0x0000000000000001 (NEEDED)             Shared library: 
[libaprutil-1.so.0]
...

   Более детальный осмотр показывает что файлы одновременно требующие 
libaprutil-1.so.0 и libdb-4.7.so по прежниму присутствуют...

> libsubversion-devel - требует оба devel'а, и требует явно.
> 
> все requires сделаны так:
> libapr1[-devel] >= 1:0.9.5-alt0.3.M24.1
> libaprutil1[-devel] >= 1:0.9.5-alt0.4
> 
> мне пока не понятна эта привязка и что там ставить сейчас.

   Судя по всему, это минимальные версии libapr[util]1 с которыми 
subversion может собраться. Чем обусловлены -- не в курсе.

> 
>> libaprutil1 вытянет libapr1 по зависимостям).
> вопрос: стоит тогда оставлять явный requires на libapr1 и libapr1-devel?

   Не требуется: libaprutil1-devel-1.3.4 требует libapr1-devel > 1.3.0 
явным образом.

> 
>>> есть вопрос: условия для сборки на M24 оставлять? есть желание её
>>> вычистить нафиг - я там не ориентируюсь :)
>>   Зависит от трудоёмкости их поддержки, думаю... (Я пока не смотрел код.)
> тогда в git'е отмечу и вышвырну эти макросы нафиг. на мастер 2.4
> бекпортить не буду точно :)

   Ваша воля.

   Для себя -- сделал систему макросов которая автоматизирует бэкпорты 
достаточно удачно. Если интересует могу залить в 
<http://git.altlinux.org/people/solo/public/?p=specs.git> (чтобы не 
тянуть историю apache`й при использовании).

-- 

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


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