[devel] [sisyphus -> devel] Стабильный Сизиф

[Alexey Tourbin]

On Mon, Jun 19, 2006 at 01:12:37PM +0300, Led wrote:
> Основные проблемы возникать могут при поступлении в incoming библиотеки с 
> новым soname.
> Упрощённо алгоритм обработки "транзакции" вижу таким образом
> 1) Была libfoo с libfoo.so.x, от которой зависят пакеты в репозитарии.
> 2) В incoming пришла libfoo м libfoo.so.y.
> 3) Попытка пересобрать зависимые пакеты роботом с вновь поступившей libfoo
> 4) Если попытка полностью успешна - commit
> 5) Если попытка (п.3) полностью или частично НЕуспешна - уведомить мэйнтейнера 
> libfoo и зависимых пакетов.
> 6) После уведомления мэйнтейнера libfoo (п.5), он должен собрать libfoo_X 
> (очень желателен скрипт-инструмент для изготовления libfoo_X.spec из 
> libfoo.spec, хотя бы частично автоматизирующий эту работу).

Либо помочь исправить пакеты, которые не удается собрать с libfoo.so.y.

> 7) После уведомления мэйнтейнеры зависимых от libfoo пакетов пересобирают свои 
> пакеты с libfoo.so.y.
> 8) В случае невозможности п.7 - мэйнтейнеры зависимых от libfoo пересобирают 
> свои пакеты с libfoo_X, или (как вариант, на котором я не настаиваю, потому 
> как "закидают гнилыми помидорами" - с libfoo.a версии X).
> 9) Если п.7 или п.8 успешны - commit.

Это разумно.  Это наводит на кое-какие мысли насчет модульной структуры
incominger'а.  То есть в данном случае после сборки каждого пакета
incominger должен попытаться обнаружить смену сонейма.  Если смена
сонейма обнаружена, в репозитарии генерируется некоторый абстрактный
"сигнал", который распространяется (propagate) на все остальные пакеты
и который система пытается обработать.  Зачатки этого подхода описаны
здесь: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_sec_3.3.4

По существу не ясно, чем гарантируется смена сонейма в конечное время.
То есть пункты 6, 7, 8 могут занять месяц, два, три...  Если для смены
каждого сонейма формировать отдельный отстойник и коммитить его целиком
только тогда, когда проблема будет полностью решена, тогда возможны
новые проблемы.  Допустим приходит новый пакет, который зависит от двух
отстойников ("транзакций").  Вопрос такой: к какому отстойнку его
отнести?  Нужно уже формировать "объединение" двух отстойников.
Если развить мысль (исходя из того, что полная смена сонейма занимает
довольно долгое время), то "объединение" нескольких отстойников
в конечном счете даст один большой новый отстойник, который до конца
переместить в сизиф никогда не удатся.  То есть будет "затык" в
альтернативном сизифе, который никак не удается слить в основной сизиф.

> Можете "пинать" ("пинки" с оскрблениями, в т.ч. в личку будут 
> проигнорированны).

Уже лучше чем про фортран и sisyphus-full. :)
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 191 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20060619/8f7b0eae/attachment-0001.bin>