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

[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)), которые
    удовлетворяются ровно одним подпакетом собираемого пакета,
    заменяются на строгие зависимости на этот подпакет без возможности
    отключения.

    (Интересно, встречаются ли реально ситуации, когда зависимость,
    найденная 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)".
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 198 байтов
Описание: Digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20130126/9976ecea/attachment.bin>