On Fri, Feb 02, 2007 at 12:53:09AM +0600, Mikhail Gusarov wrote:
> >> >> Например, rider@, обновляя вчера libcurl, обошёлся без unmet'ов.
> >> >Я бы так не стал делать (собирать compat библиотеку).
> >> А почему? Неужели сломанные пакеты - это нормальное явление?
> 
> > Ты здесь давно?
> 
> Какая разница? :-/ Проблема есть, значит нужно решать, вне зависимости
> от того, что в прошлый раз ничего не решили.

Э-э... да ты с корабля на бал!

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

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

Это означает, что compat библиотеки нужны именно мера для облегчения
пересборки/обновления системы с новой библиотекой.

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

Ой...