26.01.2013 23:07, Sergey Vlasov пишет: > On Sat, Jan 26, 2013 at 09:36:17PM +0400, Aleksey Avdeev wrote: > [...] >> Если дело в сокращении set-versions (через замену их на строгие >> зависимости), так может и ограничиться ими (простановкой строгих >> зависимостей вместо внутрипакетных set-versions) и не стоит остальное с >> плеча рубить? >> >> Как на счёт варианта: >> >> 1. Проставлять строгие зависимости вместо нестрогих с внутрипакетными >> set-versions, без возможности отключения данного механизма. >> >> 2. Во всех остальных случаях, по умолчанию менять внутрипакетные >> нестрогие зависимости на строгие, предусмотреть ручку для отключения >> таких замен. > > В соседней ветке предложен похожий вариант: > > http://lists.altlinux.org/pipermail/devel/2013-January/196540.html > > | Другими словами, предлагается модифицировать алгоритм, чтобы он работал > | следующим образом: подпакет A исходного пакета S автоматически получает > | строгую зависимость от подпакета B исходного пакета S, если выполнено любое > | из следующих условий: > | - у A есть зависимость от B; > | - у A есть такая зависимость X с атрибутом RPMSENSE_FIND_REQUIRES, что B > | является единственным подпакетом S, удовлетворяющим эту зависимость X. > > Можно переформулировать это описание таким образом: > > 1. Зависимости, найденные через find-requires (это могут быть не > только set-versions, а и, например, perl(foo.pm)), которые > удовлетворяются ровно одним подпакетом собираемого пакета, > заменяются на строгие зависимости на этот подпакет без возможности > отключения. Для меня допустимо, если явно указанные файловые зависимости ("Requires: " при наличии "Provides: " в соответствующем подпакете) под этот пункт не попадают. > > (Интересно, встречаются ли реально ситуации, когда зависимость, > найденная find-requires, удовлетворяется более чем одним > подпакетом.) > > 2. Зависимости, явно указанные в Requires, в которых указано реальное > имя подпакета, заменяются на строгие зависимости на этот подпакет > также без возможности отключения. > > (Теоретически возможна ситуация, когда имя реального подпакета > присутствует также в другом подпакете в Provides - не уверен, что > такое стоит вообще допускать; в этом случае, согласно приведённому > алгоритму, зависимость не будет заменяться на строгую.) > > 3. Зависимости, явно указанные в Requires, но с именем, не > совпадающим ни с одним реальным именем подпакета, оставляются без > изменения, даже если эта зависимость удовлетворяется ровно одним > подпакетом. > > Это правило позволяет не сломать пакеты типа xboard, в которых > присутствует подпакет, допускающий замену на альтернативные > варианты (в случае xboard в том же пакете собирается подпакет с > темой по умолчанию, но вместо него может быть установлен любой > другой пакет с темой, при этом минимум одна тема должна > присутствовать). Аналогичная ситуация и в пакете osec (с той лишь > разницей, что в данный момент в Сизифе нет ни одного пакета, > которым можно было бы заменить osec-mailreport, но указанные в > osec-cronjob зависимости позволяют создать такой альтернативный > пакет). > > Также под этот пункт могут попасть ошибочно оставленные > зависимости на устаревшее имя подпакета, если производилось > переименование подпакета с проставлением соответствующих Provides > и Obsoletes, но такую ситуацию можно обнаружить по наличию > Obsoletes с этим именем (если же ещё и Obsoletes забыли, тут уже > ничего не поможет, одна надежда на багрепорты по поводу > неработающего обновления). > > При использовании этих правил, если требуется обеспечить нестрогую > зависимость между подпакетами, собираемыми из одного исходного пакета, > такую зависимость нужно будет реализовывать через промежуточный > виртуальный пакет (при этом могут быть наложены ограничения на версию > этого виртуального пакета, отражающие особенности собираемого ПО - > например, можно требовать совпадения major-версии или какого-то > внутреннего номера версии API). > > Кстати, при анализе этих правил возник ещё один вопрос - что делать с > зависимостями, более сложными, чем "Requires: B" без указания версии, > в которых, тем не менее, указано реальное имя подпакета? Например, > если указано "Requires: B = %version" (без "-%release"), нужно ли > менять эту зависимость на строгую? А ведь возможен ещё вариант вида > "Requires: B >= x.y", для которого автоматическая замена на строгую > зависимость выглядит ещё более сомнительно (ведь зачем-то эта > нестрогая зависимость была записана именно в таком виде). Возможно, > зависимости с условием, отличающимся от "=", также стоит оставлять в > неизменном виде, что также даст возможность создания ограниченно > нестрогих зависимостей - например, в пакете версии x.y.z может быть > указано "Requires: B >= x.y" и "Conflicts: B >= x.(y+1)". У меня в качестве типовых нестрогих внутрипакетных зависимостей как правило используются: "Requires: B >= x.y", "Conflicts: С <= x.y" (где B и C как реальные так и виртуальные подпакеты) и "Requires: " (как правило при этом есть подпекет предоставляющий соответствующий "Provides: "). Принудительная замена такого рода внутрипакетных зависимостей, без возможностей её отключения -- большая засада, для меня... PS: Пересборка apache2-2.2.22-alt15 средствами librpmbuild-4.0.4-alt100.63 (на people) показала что не так страшен чёрт, как его малюют: результат вполне приемлемый, на первый взгляд. (Более детально разбтраться в понедельник буду.) -- С уважением. Алексей.