[devel] I: sendmail-8.14.0-alt1 rejected

[Mikhail Gusarov]

>> >> Например, rider@, обновляя вчера libcurl, обошёлся без unmet'ов.
>> >Я бы так не стал делать (собирать compat библиотеку).
>> А почему? Неужели сломанные пакеты - это нормальное явление?

> Ты здесь давно?

Какая разница? :-/ Проблема есть, значит нужно решать, вне зависимости
от того, что в прошлый раз ничего не решили.

> Это когда-то обсуждалось, порешили ни на чем. Пакеты, "сломанные" в
> результате смены soname, подлежат пересборке.

Подлежат, согласен.

> Трудность в том, что автоматическая пересборка не всегда
> заканчивается успешно.  Поэтому есть некоторый резон в том, чтобы
> сохранить на некоторое время библиотеку со старым soname, которая бы
> не конфликтовала (по названию и по файлам) с новой библиотекой.

Естественно. На то и soname, чтобы отмечать изменения в ABI.

> Я бы сделал так: переименовал новый libcurl в libcurl4, и больше
> ничего не делал.  Тогда старый libcurl, в виде ошметка от
> несуществующего src.rpm пакета, помог бы провести обновление более
> безболезненно.

В полноценной compat-библиотеке есть смысл: если кто-нибудь не
почешется пересобрать пакет с новой версией библиотеки, то вместо
сломанного пакета будет рабочий пакет, зависящий от
compat-библиотеки. И не придётся в случае обнаружения сломанного в
день перед релизом спешно его пересобирать, а можно будет (слегка
поматерившись в сторону ленивого майнтайнера) положить в релиз
compat-библиотеку. Замечу, что такое сочетание
(compat-библиотека+старая версия пакета) будет гораздо более
протестированным, чем новая сборка пакета с новой библиотекой.

Я бы всё-таки предложил использовать issue tracker для того, чтобы
отмечать задачи вида "этот пакет нуждается в обновлении": репозиторий
для этого подходит плохо, да и кому охота сидеть на сломанном Сизифе?
Думаю, я смогу нарисовать робота, вешающего RC-баги на пакеты,
зависящие от библиотеки, перемещаемой в oldlibs, или следить за этим
ручками.

-- 
JID: dottedmag на jabber.dottedmag.net