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

[Led]

В сообщении от 19 июня 2006 15:12 Alexey Tourbin написал(a):
> 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 могут занять месяц, два, три...

А это и есть пресловутый "человеческий фактор" - без него никак :( Чтоб не 
было "месяц-два-три" и привёл пункт 6. Либо новая libfoo не пропускается 
вобще, либо мэйнтейнеру нужно немножко озадачиться изготовлением libfoo_X 
(думаю, если продумать policy на libfoo => libfoo_X, то и "заскриптовать" это 
будет возможно).

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

Возможно "отстойник" стОит "залочить" от "внешего вмешательства", т.е. пока 
транзакция не завершена, ничего увеличивающего энтропию в неё не добавлять.

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

Я уже понял, что кроме смайликов надо ещё слово "ЛОПАТА" ставить, чтоб не 
нарваться:)

-- 
Led.