[devel] dependency needs Epoch warnings

[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, см. <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
которая такую гарантию дает.

> PS: Для меня проще всего забить на проблему, поставив строгие
> зависимости. Но это ударит по пользователям. Особенно по тем, у кого
> слабый канал (такой как аналоговый модем или GPRS) или вообще отсутствие
> оного (выкачка пакетов сторонними средствами и последующая установка с
> носителя).

Мы говорим о потенциальных пользователях, которые не смогут обновить
apache2-base, или такие пользователи действительно существуют?


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