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, развёрнтый ответ пишу. >> >> См. соседнее письмо >> (). >> >>>> >>>>> >>>>>> В противном случаи будет сломана >>>>>> возможность делать точечные обновления компонентов apache2 и возможность >>>>>> установки новых модулей (или их версий) на старый apache2 (если нет >>>>>> противопоказаний по библиотекам, разумеется). >>>>> >>>>> Такая возможность не просто не нужна, она вредна и с ней надо бороться. >>>>> При сборке apache2 тестируется в лучшем случае модули и сервер, собранные >>>>> из одного исходного пакета, и не надо делать вид, что модули и сервер, >>>>> собранные из разных исходного пакета, могут случайно заработать. >>>> >>>> Для apache это скорее правило чем исключение: >>>> >>>> 1. Все заведомо несовместимые модули отстреливаются по MMN (Module Magic >>>> Number, см. ), за >>>> которым следит арстрим. У нас это реализовано через предоставление >>>> зависимости 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. А это (судя >> по ) 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 не идёт в Сизиф, пока у меня нет такого рецепта, т. к. она не проходит мои внутренние тесты на виртуалках.) И вот эта задача, зависимости для "родных" и "сторонних" модулей по одной схеме, без нестрогих зависимостей решается плохо (слишком много накладных расходов для "сторонних"). -- С уважением. Алексей.