[devel] Рано поднимать до error

[Aleksey Avdeev]

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: <file>" при наличии "Provides: <file>" в соответствующем
подпакете) под этот пункт не попадают.

> 
>     (Интересно, встречаются ли реально ситуации, когда зависимость,
>     найденная 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: <file>" (как
правило при этом есть подпекет предоставляющий соответствующий
"Provides: <file>"). Принудительная замена такого рода внутрипакетных
зависимостей, без возможностей её отключения -- большая засада, для меня...

PS: Пересборка apache2-2.2.22-alt15 средствами
librpmbuild-4.0.4-alt100.63 (на people) показала что не так страшен
чёрт, как его малюют: результат вполне приемлемый, на первый взгляд.
(Более детально разбтраться в понедельник буду.)

-- 

С уважением. Алексей.


----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 900 байтов
Описание: OpenPGP digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20130127/4c1e0974/attachment-0001.bin>