24.01.2013 23:15, Dmitry V. Levin пишет: > 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}? > От этого действительно может быть какая-то польза? Или все это > разнообразие упаковывается просто потому, что это возможно? Действительно нужно: у нас сейчас содержимое /var/www/{html,cgi-bin,icons} представлено в двух, конфликтующих между собой, вариантах: "от apache" и "от apache2" (см. ). И при этом есть запросы вида (см. , как пример дискуссии): 1. "Хочу иметь апстримное содержимое /var/www/ от apache2, если я apache2 ставлю." -- решается пакетом apache2-full, вытягивает apache2-{cgi-bin,html,icons}. 2. "Хочу иметь апстримное содержимое /var/www/ от apache, если я apache ставлю." -- решается пакетом apache-full, вытягивает apache-{cgi-bin,html,icons}. 3. "Нужно хоть что-то в /var/www/, если я ставлю apache{,2}." -- решается apache{,2}, требующими webserver-{cgi-bin,html,icons} (и вытягиваущими apache2-{cgi-bin,html,icons} по факту). 4. "Нужен пустой /var/www/, если я ставлю apache{,2}." -- решается apache{,2}-base. > >> 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 от разных сборок > одновременно? Мне кажется, что здесь чем проще, тем лучше. Да. apache2-base это: конфиги (и их примеры), стартовые файлы httpd2 (для init/systemd), вспомогательные утилиты, сообщения об ошибках и пр. инфраструктура. apache2-common же это в основном модули и конфиги (и утилиты) для них (хотя куски инфраструктуры там тоже есть). Для закрытия большинства багов связанных с безопасностью (CVE и подобные) достаточно обновить только apache2-common (если проблемный модуль там, или другой нужный apache2-mod_*) и используемый apache2-httpd-* (причём, в заметном числе случаев, когда бага и исправление затрагивают только модуль, его тоже трогать не нужно). > >> 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 >> >> Комплект конфигов. Совместимость учтена через зависимости. > > Не понимаю. $ rpm -ql apache2-configs-A1PROXIED /etc/httpd2/conf/ports-available/http-A1PROXIED.conf /etc/httpd2/conf/ports-enabled/http-A1PROXIED.conf /etc/httpd2/conf/ports-start.d/020-A1PROXIED.conf /etc/httpd2/conf/sites-available/vhosts-A1PROXIED.conf /etc/httpd2/conf/sites-enabled/vhosts-A1PROXIED.conf /etc/httpd2/conf/sites-start.d/020-A1PROXIED.conf Для пакета необходимо только чтобы существовали инклюдируемые файлы: /etc/httpd2/conf/ports-available/http{,-localhost-8088}.conf для /etc/httpd2/conf/ports-available/http-A1PROXIED.conf и /etc/httpd2/conf/sites-available/vhosts{,-8088}.conf для /etc/httpd2/conf/sites-available/vhosts-A1PROXIED.conf. Всё остальное (в том числе _версия_ бинарников apache2 и содержимое инклюдируемых файлов) -- данному пакету глубоко фиолетово. > >> 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 от разных сборок. Здесь, пожалуй да: apache2-httpd-* пакеты маленькие. (Хотя релизы с фактическим обновлением только кода модулей у apache2 бывают.) > >> >> error: apache2-manual: non-strict dependency on apache2-base >> error: apache2-manual: non-strict dependency on apache2-common >> >> Это контент. Заведомо будет работать с любыми совместимыми версиями >> (задано нестрогими зависимостями и конфликтами). Точнее это конфиги + ссылка на контент. > > И в каких случаях такая свобода выбора могла бы быть полезна? Когда необходимо закрыть дыру (затронут один из используемых модулей) используя минимальное количество пакетов. Например, когда пакеты ставятся с носителя на которой их выкачивают вручную через GPRS. А если ещё в режиме телефонного управления ("обезьяна на телефоне"), когда действия с консолью выполняет неподготовленный пользователь, которым ты управляешь по телефону (был у меня подобный опыт). > >> 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 от разных сборок. Например, когда срочно нужно закрыть дыру в mod_ssl, mod_suexec или mod_disk_cache (не затрагивающею httpd2 и модули apache2-common) в условиях необходимости минимизации числа устанавливаемых пакетов (см. пример выше). Кроме того, на этих пакетах решается, и тестируется, задача корректной установки зависимостей для сторонних модулей apache2. Подробности в соседнем письме (см. ). > >> 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, > все это выборное разнообразие выглядит самым что ни на есть сферическим > индейцем в вакууме. Это разнообразие позволяет закрыть дыру, локализованную в неком бинарном компоненте apache2 (в модуле или демоне), обойдясь точечным обновлением минимального количества пакетов. И как правило оно удаётся. (Кроме периодов инфраструктурных изменений в apache2 или системе.) -- С уважением. Алексей.