On Thu, Jan 24, 2013 at 09:58:12PM +0400, Aleksey Avdeev wrote: > 24.01.2013 15:25, Dmitry V. Levin пишет: > > On Thu, Jan 24, 2013 at 02:47:26PM +0400, Aleksey Avdeev wrote: > >> 24.01.2013 10:44, Dmitry V. Levin пишет: > >> ... > >>> В rpm-build-4.0.4-alt100.61 этот warning превратился в error, > >>> и добавлен макрос %_allowed_nonstrict_interdeps для тонкой настройки > >>> списка разрешенных пар нестрогих зависимостей: > >>> %define _allowed_nonstrict_interdeps pkg11,pkg12 ... pkgN1,pkgN2 > >> > >> Прошу уточнения: > >> > >> 1. Имеется в виду, что пакет из данного списка может иметь нестрогие > >> зависимости на любой другой пакет из него же? > >> > >> 2. В каком виде должны присутствовать имена пакетов в списке: > >> %name- или достаточно ? > > > > Имеется в виду, что каждый случай применения этого макроса стоит проводить > > через обсуждение в этом списке, хотя бы только для того, чтобы убедиться, > > что нестрогие зависимости в данном конкретном пакете действительно имеют > > смысл, а не являются следствием приземления благих намерений. > > Тогда давайте обсуждать apache2, то что сейчас собираю (см. > ): > > error: apache2: non-strict dependency on apache2-cgi-bin > error: apache2: non-strict dependency on apache2-html > error: apache2: non-strict dependency on apache2-icons > > Вызвано зависимостями: > > Requires: webserver-cgi-bin > Requires: webserver-html > Requires: webserver-icons > > Данные зависимости предоставляют не только пакеты > apache2-{cgi-bin,html,icons}, но и apache-{cgi-bin,html,icons}. И пакету > apache2 _действительно_ всё равно, какие именно пакеты данные > зависимости реализуют. Нам действительно нужно много разных вариантов apache*-{cgi-bin,html,icons}? От этого действительно может быть какая-то польза? Или все это разнообразие упаковывается просто потому, что это возможно? > error: apache2-base: non-strict dependency on apache2-common > > apache2-base это в основном сборище конфигов, каталогов и пр. не > исполняемых файлов. Бинарные вспомогательные утилиты там тоже есть, но > от бинарного содержимого apache2-common (и его ABI) они не зависят. > Несовместимости учтены зависимостями вида > Requires: %name-common > 2.2.22-alt11 в самом пакете и конфликтами вида > Conflicts: apache2-base <= 2.2.22-alt11 в apache2-common. Есть ли смысл использовать apache2-base и apache2-common от разных сборок одновременно? Мне кажется, что здесь чем проще, тем лучше. > error: apache2-base: non-strict dependency on apache2-httpd-worker > error: apache2-base: non-strict dependency on apache2-httpd-prefork > error: apache2-base: non-strict dependency on apache2-httpd-event > error: apache2-base: non-strict dependency on apache2-httpd-itk > error: apache2-base: non-strict dependency on apache2-httpd-peruser > > Вызвано требованием: > > Requires: %apache2_sbindir/%apache2_dname > > т. к. файл %apache2_sbindir/%apache2_dname альтернатива, предоставляемая > всеми перечисленными подпакетами > (apache2-httpd-{worker,prefork,event,itk,peruser}). Вот это очень похоже на реальную альтернативу, где неявность зависимости объективно связана с возможностью осмысленного выбора. > error: apache2-configs-A1PROXIED: non-strict dependency on apache2-base > error: apache2-configs-A1PROXIED: non-strict dependency on apache2-common > > Комплект конфигов. Совместимость учтена через зависимости. Не понимаю. > error: apache2-httpd-worker: non-strict dependency on apache2-common > error: apache2-httpd-prefork: non-strict dependency on apache2-common > error: apache2-httpd-event: non-strict dependency on apache2-common > error: apache2-httpd-itk: non-strict dependency on apache2-common > error: apache2-httpd-peruser: non-strict dependency on apache2-common > > Фактически, здесь недолинкованные библиотеки (модули > в apache2-common) зависят от бинарников, подставляемых пакетми > apache2-httpd-{worker,prefork,event,itk,peruser} через альтернативу > %apache2_sbindir/%apache2_dname (/usr/sbin/httpd2), но направление > зависимостей выставлено обратным. Т. е. для rpm не модули > (apache2-common) зависят от исполняемых бинарников (/usr/sbin/httpd2), > что имеет место быть по факту, а бинарники (пакеты apache2-httpd-*) от > модулей (apache2-common). (Пакет apache2-common выбран центральной > сущностью.) > > От проблем защищают: > > 1. Привязка к конкретному MMU (Module Magic Number, см. > ) (apache2-common > предоставляет %name-mmn = %mmn, а apache2-httpd-* его _строго_ требуют). > > 2. Есть защита от использования не той libaprutil1, через: > > а) Requires: libaprutil1 >= %n_aprutil_devel_ver в apache2-common > (%n_aprutil_devel_ver соответствует версии-релизу пакета > libaprutil1-devel использованного при сборке). > > б) Автозависимость вида libaprutil-1.so.0()(64bit) >= set:... (наши > set-version, или как их назвать правильно) в пакетах > apache2-httpd-{worker,prefork,event,itk,peruser}. > > Т. е. сейчас я считаю что пакет libaprutil1 такой-же или более новый чем > libaprutil1-devel использованный при сборке, скорее всего подойдёт для > модулей (в apache2-common). (С пакетами apache2-httpd-* проще -- там > set-version работает.) > > Понятно что это тонкое место, и что для модулей нужно делать > автогенирацию нечто подобного /usr/sbin/httpd2 >= set:... (по аналогии > set-version сделанного для библиотек), но я не знаю как подступиться к > данной задачи. > > Что здесь стоит сделать (могу, достаточно быстро): > > 1. Удалить устаревшие, не актуальные, условия (например, сейчас по > факту, от libssl зависит только apache2-mod_ssl). > > 2. Сделать защиту от использования не той libapr1 (по аналогии > сделанного для libaprutil1). > > 3. Сделать привязку к версии libpcre (требуется apache2-httpd-*, для > apache2-common похоже не нужно, но может потребоваться другим модулям). Мне кажется, что здесь было бы вполне естественно просто поставить строгую зависимость apache2-httpd-* на apache2-common; мы ведь практически ничего не выигрываем от того, что существует возможность одновременно установить apache2-httpd-worker и apache2-common от разных сборок. > > error: apache2-manual: non-strict dependency on apache2-base > error: apache2-manual: non-strict dependency on apache2-common > > Это контент. Заведомо будет работать с любыми совместимыми версиями > (задано нестрогими зависимостями и конфликтами). И в каких случаях такая свобода выбора могла бы быть полезна? > error: apache2-mod_ldap: non-strict dependency on apache2-common > > Фактические требования модуля совпадают с требованием модулей > находящихся в apache2-common. Но т. к. apache2-common выбран центральной > сущностью -- все завязано на него. Модуль не зависит от > %apache2_sbindir/%apache2_dname, но требуют: > > PreReq: %name-common > Requires: %name-mmn = %mmn > Requires: libaprutil1-ldap >= %n_aprutil_devel_ver > > error: apache2-mod_disk_cache: non-strict dependency on apache2-common > error: apache2-mod_ssl: non-strict dependency on apache2-common > error: apache2-suexec: non-strict dependency on apache2-common > > Практически аналогично apache2-mod_ldap. (Но похоже нужно использовать > Requires: libaprutil1 >= %n_aprutil_devel_ver -- сейчас зависимости на > libaprutil1 сдесь нет.) Опять же, не вижу, какая могла бы быть польза в возможность одновременно установить эти пакеты и apache2-common от разных сборок. > error: apache2-compat: non-strict dependency on apache2-base > error: apache2-compat: non-strict dependency on apache2-common > error: apache2-mod_ssl-compat: non-strict dependency on apache2-common > > Конфиги. С бинарниками напрямую не связанны. Oт apache2-{base,common} > нужна инфроструктура и работающие с ней утилиты. > > error: apache2-cgi-bin-test-cgi: non-strict dependency on apache2-datadirs > error: apache2-cgi-bin-printenv: non-strict dependency on apache2-datadirs > > CGI скрипты. С бинарниками напрямую не связанны. > > error: apache2-htcacheclean: non-strict dependency on apache2-mod_disk_cache > > Обусловлено требованием каталога, содержащегося > в apache2-mod_disk_cache: > > Requires: %apache2_htcacheclean_cachepath За исключением альтернативных провайдеров %apache2_sbindir/%apache2_dname, все это выборное разнообразие выглядит самым что ни на есть сферическим индейцем в вакууме. -- ldv