[devel] Зависимости между apache2-httpd-* и apache2-{mod_*,common}

Пт Янв 25 02:26:14 MSK 2013

25.01.2013 01:47, Dmitry V. Levin пишет:
> On Fri, Jan 25, 2013 at 01:44:09AM +0400, Aleksey Avdeev wrote:
>> 24.01.2013 20:52, Dmitry V. Levin пишет:
>>> On Thu, Jan 24, 2013 at 04:21:11PM +0400, Aleksey Avdeev wrote:
>>>> 24.01.2013 15:31, Dmitry V. Levin пишет:
>>>>> On Thu, Jan 24, 2013 at 02:25:06PM +0400, Aleksey Avdeev wrote:
>>>>>> 24.01.2013 10:53, Dmitry V. Levin пишет:
>>>>>>> По моим данным, в Сизифе 44 пакета, которые собираются с этим
>>>>>>> предупреждением, например:
>>>>>>> $ grep '^warning: [^:]*: dependency on [^ ]* needs Epoch' xorg-server-2:1.13.1.901-alt1 
>>>>>>> warning: xorg-server: dependency on xorg-server-common needs Epoch
>>>>>>> warning: xorg-drv-multimedia: dependency on xorg-server needs Epoch
>>>>>>> warning: xorg-xephyr: dependency on xorg-server needs Epoch
>>>>>>> warning: xorg-xdmx: dependency on xorg-server needs Epoch
>>>>>>> warning: xorg-xvfb: dependency on xorg-server-common needs Epoch
>>>>>>> warning: xorg-xnest: dependency on xorg-server-common needs Epoch
>>>>>>>
>>>>>>> То, что этот warning пора поднять до error, кажется очевидным.
>>>>>>> Вопрос, есть ли смысл делать ручку, которая бы понижала этот error
>>>>>>> обратно до уровня warning?
>>>>>>
>>>>>>   Нужно как миниум для apache2.
>>>>>
>>>>> Словам не верю, докажите.
>>>>
>>>>   OK, развёрнтый ответ пишу.
>>
>>   См. соседнее письмо
>> (<http://lists.altlinux.org/pipermail/devel/2013-January/196451.html>).
>>
>>>>
>>>>>
>>>>>> В противном случаи будет сломана
>>>>>> возможность делать точечные обновления компонентов apache2 и возможность
>>>>>> установки новых модулей (или их версий) на старый apache2 (если нет
>>>>>> противопоказаний по библиотекам, разумеется).
>>>>>
>>>>> Такая возможность не просто не нужна, она вредна и с ней надо бороться.
>>>>> При сборке apache2 тестируется в лучшем случае модули и сервер, собранные
>>>>> из одного исходного пакета, и не надо делать вид, что модули и сервер,
>>>>> собранные из разных исходного пакета, могут случайно заработать.
>>>>
>>>>   Для apache это скорее правило чем исключение:
>>>>
>>>> 1. Все заведомо несовместимые модули отстреливаются по MMN (Module Magic
>>>> Number, см. <http://httpd.apache.org/docs/2.2/glossary.html>), за
>>>> которым следит арстрим. У нас это реализовано через предоставление
>>>> зависимости Provides: %name-mmn = %mmn (где %mmn константа,
>>>> соответствующая собираемому apache2) пакетом apache2-commom (все модули
>>>> должны требовать зависимость с нужным им MMN).
>>>>
>>>> 2. Изменения сонеймов библиотек, с которыми собирается apache2, тоже
>>>> кодируются в виде зависемостей предоставляемых пакетом apache2-commom.
>>>> Список, правда, контролируется руками, и сейчас там только openssl:
>>>>
>>>> Provides: %name-%apache2_libssl_name = %apache2_libssl_soname
>>>>
>>>> где (см. пакет rpm-macros-apache2):
>>>>
>>>> %apache2_libssl_name libssl
>>>>
>>>> %apache2_libssl_soname %(rpm -qR %apache2_libssl_name-devel | sed -rn
>>>> '/^[[:space:]]*%apache2_libssl_name[0-9.]+[[:space:]]+[=<>]/s/^[[:space:]]*libssl([0-9.])+[[:space:]]+[=<>].*$/\\1/p')
>>>>
>>>> Если список надо расширить -- предложения принимаются. (Ранее, подобным
>>>> механизмом контролировался и сонейм lindb4, но теперь apache2 напрямую с
>>>> lindb4 не линкуется.)
>>>>
>>>> 3. Многие библиотеки apache2 использует через libapr/libaprutil, которые
>>>> и скрывают изменения их ABI.
>>>>
>>>> 4. Наши set-version для библиотек снимают заметную часть проблем.
>>>>
>>>>   Это касательно ABI. Требования по каталогам/файлам и содержимым
>>>> конфигов я контролирую руками.
>>>
>>> Это все сложно и не дает гарантии, в отличие от простой конструкции вида
>>> Requires: %name = %{?epoch:%epoch:}%version-%release
>>> которая такую гарантию дает.
>>
>>   Даст. Но она приведёт к строгой привязки модулей к тому бинарнику
>> /usr/sbin/httpd2, для которого они собирались => вызовет строгую
>> необходимость пересборки всех пакетов предоставляющих подпакеты
>> apache2-mod_* (т. к. их требования к /usr/sbin/httpd2 ничем не
>> отличаются от требований модулей находящихся в apache2-common) в рамках
>> одной транзакции, при сборке каждого из _релизов_ apache2. А это (судя
>> по <http://sisyphus.ru/ru/find.shtml?request=apache2-mod_>) 32 пакета,
>> из которых мой только 1 (сам apache2).
> 
> Вы чего-то не поняли.  Все нестрогие зависимости, которые диагностирует
> rpmbuild, относятся _исключительно_ к внутрипакетным зависимостям.
> Так, нестрогие зависимости в apache2 - это нестрогие зависимости только
> тех пакетов, которые получаются при сборке самого apache2.

  Это я понял. Как и то, что нет проблемы поставить строгую зависимость
между пакетами apache2-httpd-* (содержащими /usr/sbin/httpd2) и пакетами
с модулями apache2-{mod_*,common} собираемыми из одного
apache2-*.src.rpm. Здесь, в такой постановке, действительно проблем нет.
Но это приведёт к тому, что зависимости для "родных" (собираемых из
дистрибутива apache2) и "сторонних" модулей apache2 нужно будет ставить
по разным схемам...

  А я то стараюсь проставить зависимости между apache2-httpd-*
apache2-{mod_*,common} по той же схеме, как они будут стоять между
apache2-httpd-* и _сторонними_ apache2-mod_*! (Это возможно, т. к. и
"родные" модули apache2 и "сторонние" используют общий интерфейс
/usr/sbin/httpd2.) Такой подход позволяет:

1. Обнаруживать львиную долю проблем точечного обновления apache2 и его
модулей на этапе внутреннего тестирования новой сборки apache2, в
процессе точечного поэтапного обновления компонентов работающего apache2
в тестовой виртуалке.

2. Всегда иметь готовый (протестированный) рецепт по исправлению проблем
с зависимостями для мантейнеров сторонних apache2-mod_*. (Сборка apache2
не идёт в Сизиф, пока у меня нет такого рецепта, т. к. она не проходит
мои внутренние тесты на виртуалках.)

  И вот эта задача, зависимости для "родных" и "сторонних" модулей по
одной схеме, без нестрогих зависимостей решается плохо (слишком много
накладных расходов для "сторонних").

-- 

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

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