[devel] Зависимости между apache2-httpd-* и apache2-{mod_*,common} (was: dependency needs Epoch warnings)
Aleksey Avdeev
solo на solin.spb.ru
Пт Янв 25 01:44:09 MSK 2013
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).
Считаем такой подход (модули строго зависят от /usr/sbin/httpd2 с
заданными %{?epoch:%epoch:}%version-%release) вариантом 0.
На мой взгляд, возможны более мягкие варианты, с меньшей надёжностью,
но и меньшими накладными расходами на поддержку. Но они тоже будут
использовать нестрогие зависимости (+ зависимости специального вида).
$ rpm -qR apache2-httpd-prefork
...
/lib64/ld-linux-x86-64.so.2
libapr-1.so.0()(64bit) >=
set:mdScRzxUDK08PLNebAfs84ljmWQtoHRtFuNahVkzKhJ77vOoVPtNr9RLoLhKk2sSXCq4H4eVnVZw1I85fDiBiZshOi3Pan6ezU26kEnODWphetGh2qO9QAlvlOij3ZlJErbZwaLBhccEcR1TK0n2ZxDxi4UDau01gEU91gDZ2wpIHIgAEGpQdYZtRIpu8ZoiRNFGRE0EZBzU3cJcgbHHzg81FFxmpyZkRgKDmQ2ua7ii5eITpuR4XFBR6xqwx7etV9ggp1EwsxtZ0rJD1lz6B5RLU0Zm41aOE64t2Z0hob5PXO5sLoG4AqyXiF8LDQZsxhQit1kTfHoZ8rr88haHXOB0PGZb7abFhZ12BePFn92NY0uhFYtxSM5rosXE1lxn9P1mHuIILqgUzs8RgvbmKPx4PwNB2PNJTLGyYoA2etXD9xIKhTA0ry6rNXDYO3GI0wfkhaI0k8zI67pG5cxApZGd7c1673bgFG9pL5Q8Kui5Z4Btmee4TPPQAi6hotCJoqAWFmNpbTYDisGfwY3j7nwx7cDqObUdHnHqqlUYgqejQK323k1aCfKfldECre5vnb4kuqQhdA2lKGxDlZu1a5AvRfZrg34Z9icOsScUBJ56JWXBMxE9wZwDF6083hCIykyCH5tfz8SI76cU6ixPRMB8rGEREZkAUNtsZ4ihY8pkVthZALvHPKn35ZsW8ZCGNWP1goVgGIzb4R63iVYxMXO7sNozU3ZrZewBZz4GiP9qYeVz3aQ9c7QVp8KUovwc7bDygRrIweB1noWF7dabLRRFqgaGGpaES4AZjIPCh6RnmPZaXzzlmysmsJYfAXoaIE7ejkwymXgqW18wq8QkSxD0L4hyv05nc0SR
rpmlib(SetVersions)
libaprutil-1.so.0()(64bit) >=
set:mdUR3aDfv8HX6HeiQIZfdNeVW0V0QCackx0AiRnCw0xLAl6KIlSq1IkpGRJ6B0EeRcgsethSxoyZ1Z83VATVj0Fpa3rG8Pn3lSEe41mf8oYIwXx2zjobEA3QsKd11g82cIZayfl0yH4rZ9siejISsnYbOw5fUbhs7D38T9Mq15kesYEFWMJ70TmCbgg9i4ykogWIDkKyiFoCfCAy7ZwKyH9GRuZdeylMVi4O5SIWpzv8AkjHbSOl1xyDsyAZevCUUPg7g2BG3fdNGLaEp1d04Ac3ckBWBPH5EayRVEm0VQbo9mzG2R61j9gkEJ9Rw8dVnZdt8pifxASid0b1FccqxGC920nbTpJ7m3uNEUZv4zUZzmu0a6Q2djK19jrQVIl01Pn7E4q928Zt2VoZhIZ2E469Sfz6NjTb0gXk7vC0sJQZmz0EutERAYyZp1kA5hpd8g1QfEY1T1Jq421xhCAEet961j12yxczG82FtlWKZtDMS1WKXoaks1ZsN18vJ7aoCXUg3COhvL2z8p3qfJ3udwijz8zyVO1PkPpvS1
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libpcre.so.3()(64bit) >= set:jgnWvEIM1hju
libpthread.so.0(GLIBC_2.2.5)(64bit)
Видно, что если не учитывать lib64/ld-linux-x86-64.so.*, libc.so.* и
libpthread.so.*, то по библиотекам пакет зависит то libapr-1.so.*
(libapr1), libaprutil-1.so.* (libaprutil1) и libpcre.so.* (libpcre3) =>
(при неизменном MMN) ABI можно считать зависимым только от данных
библиотек =>:
1. Для поддержки "строгих" (частично ослабленных) зависимостей нам
достаточно чтобы модули собирались с теми
%{?epoch:%epoch:}%version-%release libapr{,util}1-devel
и libpcre-devel, что и apache2-httpd-*. Это позволит отказаться от
переборки сторонних пакетов apache2-mod_* при _каждом_ обновлении
apache2. Достаточно будет переборки при изменении libapr{,util}1-devel
или libpcre-devel. Но комплект из apache2 и _всех_ сторонних
apache2-mod_* придётся пересобирать при _каждых_ обновлениях
libapr{,util}1 и libpcre3 (и не исключено что одной транзакцией).
2. Если считать, что без изменения сонейма апстримы libapr{,util} и
libpcre обратную совместимость ABI не ломают, то можно считать
достаточным чтобы пакеты apache2-mod_* и apache2-httpd-* требовали
пакеты libapr{,util}1 и libpcre3 с %{?epoch:%epoch:}%version-%release >=
чем было предоставлено пакетами libapr{,util}1-devel и libpcre-devel с
которыми они (модули и бинарник) собирались. Этот вариант самый лёгкий в
поддержке.
Свожу варианты:
0:
+:
а) надёжность максимальна;
б) проще всего реализуется в спеке;
в) нет нестрогих зависимостей;
-:
а) наибольшая трудоёмкость в поддержке: при _любом_ обновлении
apache2 -- пересборка _всех_ пакетов предоставляющих apache2-mod_*);
6) мне нужны будут права на NMU всех пакетов предоставляющих
apache2-mod_* (или придётся каждый раз ждать, пока владельцы затронутых
пакетов дадут разрешение на их пересборку);
1:
+:
а) если libapr{,util}1 и libpcre3 не менялись -- при сборках apache2
можно не трогать пакеты предоставляющие apache2-mod_* => меньше дёргать
сторонние пакеты => поддерживать проще чем вариант 0;
-:
а) меньшая надёжность чем в варианте 0;
б) конструкции в спеке сложнее чем в варианте 0;
в) мне нужны будут права на NMU всех пакетов предоставляющих
apache2-mod_* (или придётся каждый раз ждать, пока владельцы затронутых
пакетов дадут разрешение на их пересборку, как и в варианте 0);
2:
+:
а) если сонейм libapr{,util} и libpcre не менялся (и они по прежнему
libapr{,util}1 и libpcre3) -- пересборка apache2 сторонние apache2-mod_*
не затрагивает => жёсткой синхронизации сборок apache2 и сторонних
apache2-mod_* не требуется => поддержка проще чем вариант 1 (и
значительно проще чем вариант 0);
б) NMU на сторонние пакеты не требуется и никого ожидать не нужно;
-:
а) надёжность меньше чем у варианта 1;
б) конструкции в спеке сравнима с вариантом 1 => сложнее чем в
варианте 0;
Используемый сейчас вариант, по факту, менее надёжен чем вариант 2.
>
>> PS: Для меня проще всего забить на проблему, поставив строгие
>> зависимости. Но это ударит по пользователям. Особенно по тем, у кого
>> слабый канал (такой как аналоговый модем или GPRS) или вообще отсутствие
>> оного (выкачка пакетов сторонними средствами и последующая установка с
>> носителя).
>
> Мы говорим о потенциальных пользователях, которые не смогут обновить
> apache2-base, или такие пользователи действительно существуют?
То что пользователи сидящие на слабом и/или ограниченном (медленном,
дорогом не безлимитном и пр.) канале (или вообще без оного) существуют
-- для меня очевидно: голоса таких пользователей до сих пор встречаются
на LOR, opennet и иногда в наших рассылках. Как правило это люди из
глубинки (мест в десятки-сотни километров в стороне от региональных
центров) или администраторы обособленных систем, не подключённых к
интернет (например технологическое оборудование). Насколько это
множество пересекается с множеством наших пользователей (в смысле: тех
чьё мнение для нас, как Team, важно) -- я не знаю.
Иногда таким пользователем являюсь я сам, когда тестирую
обновления/работу компонентов apache2 физически находясь на даче (Лен.
обл.) или в деревне (Новгородская обл.): Пакетирование и тестирование
тогда идет локально, на ноуте, а сборка -- удалённо (git.alt или
people). При этом ситуация, когда можно закачать только выбранные
пакеты, а не весть комплект, существенно снижает время закачки (в
деревне GPRS хренов: вышка далеко и телефон держит только 1-2 палки) и
финансовые затраты.
--
С уважением. Алексей.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : signature.asc
Тип : application/pgp-signature
Размер : 900 байтов
Описание: OpenPGP digital signature
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20130125/87a0fdb0/attachment-0001.bin>
Подробная информация о списке рассылки Devel