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 которая такую гарантию дает. > PS: Для меня проще всего забить на проблему, поставив строгие > зависимости. Но это ударит по пользователям. Особенно по тем, у кого > слабый канал (такой как аналоговый модем или GPRS) или вообще отсутствие > оного (выкачка пакетов сторонними средствами и последующая установка с > носителя). Мы говорим о потенциальных пользователях, которые не смогут обновить apache2-base, или такие пользователи действительно существуют? -- ldv