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). Считаем такой подход (модули строго зависят от /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 палки) и финансовые затраты. -- С уважением. Алексей.