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

[Led]

В сообщении от 19 июня 2006 16:03 Alexey Tourbin написал(a):
> On Mon, Jun 19, 2006 at 03:26:26PM +0300, Led wrote:
> > > По существу не ясно, чем гарантируется смена сонейма в конечное время.
> > > То есть пункты 6, 7, 8 могут занять месяц, два, три...
> >
> > А это и есть пресловутый "человеческий фактор" - без него никак :( Чтоб
> > не было "месяц-два-три" и привёл пункт 6. Либо новая libfoo не
> > пропускается вобще, либо мэйнтейнеру нужно немножко озадачиться
> > изготовлением libfoo_X (думаю, если продумать policy на libfoo =>
> > libfoo_X, то и "заскриптовать" это будет возможно).
>
> Кстати изготовление отдельного пакета libfoo_X в ряде случаев
> нежелательно.  Потому что библиотеки libfoo_X и libfoo_Y могут оказаться
> в одном адресном пространстве, что может быть фатальным.  Гипотетический
> пример: библиотека libbar зависит от glib1, а библиотека libbaz зависит
> от glib2.  Приложение, которое использует libbar и libbaz одновременно,
> загружает в свое адресное пространство сразу glib1 и glib2.  Я не знаю,
> насклько ELF/ld.so умеет или пытается разруливать такие ситуации, но в
> общем-то ясно, что это может кончиться очень плохо.
>
> > > Если для смены
> > > каждого сонейма формировать отдельный отстойник и коммитить его целиком
> > > только тогда, когда проблема будет полностью решена, тогда возможны
> > > новые проблемы.  Допустим приходит новый пакет, который зависит от двух
> > > отстойников ("транзакций").  Вопрос такой: к какому отстойнку его
> > > отнести?  Нужно уже формировать "объединение" двух отстойников.
> > > Если развить мысль (исходя из того, что полная смена сонейма занимает
> > > довольно долгое время), то "объединение" нескольких отстойников
> > > в конечном счете даст один большой новый отстойник, который до конца
> > > переместить в сизиф никогда не удатся.  То есть будет "затык" в
> > > альтернативном сизифе, который никак не удается слить в основной сизиф.
> >
> > Возможно "отстойник" стОит "залочить" от "внешего вмешательства", т.е.
> > пока транзакция не завершена, ничего увеличивающего энтропию в неё не
> > добавлять.
>
> Что значит залочить от внешнего вмешательства?  То есть допустим
> сменился soname у libjpeg, и под это дело выделяется отдельный
> отстойник, пока все пакеты не будут пересобраны с новым libjpeg.
>
> Вновь посутпающие пакеты должны пересобираться в отстойнике или
> на сизифе без отстойника?  Очевидно, в отстойнике, иначе не выполняется
> требование завершения транзакции (все пакеты должны пересобраться с
> новой библиотекой libjpeg).
>
> Через месяц меняется soname у libssl.  Транзакция по libjpeg ещё не
> завершена.  Нужно формировать новый отстойник для libssl, или вообще
> зарубить libssl на том основании, что "отстойник залочен", т.е. в
> отдельный момент времени нельзя допускать более одной тразакции по смене
> сонейма?
>
> Допустим, есть два отстойника (уже пересказываю) по libjpeg и libssl.
> Теперь идёт пакет, который зависит одновременно от libjpeg и libssl.
> В каком отстойнике собирать этот пакет?  Очевидно, что условие
> завершения одной из транзакций будет нарушено.  Тогда нужно слить два
> этих отстойника вместе и собирать этот пакет на объединенном отстойнике
> libjpeg+libssl.  После этого условие завершения объединенной транзакции
> становится гораздо сложнее.  Короче, слияние отстойников формирует
> "параллельный сизиф", а транзакцию по объединенному отстойнику завершить
> никогда не удается.
>
> Так можно ли автоматически бороться с анметами (то есть существует ли
> более тонкий автоматический критерий, чем просто давать reject пакетам,
> которые увеличивают количество анметов)?

Ок, попробую объяснить по другому (вариант libfoo_X для упрощения пока не 
учитываю - он был приведён как временное решение, "костыль" для быстрейшего 
(надеюсь, только в некоторых случаях) завершения транзакции в 
случае "ленивости" мэйнтейнеров зависимых пакетов):
1) Термин "отстойник" и то, что вы в него вкладываете не совсем подходит
2) Предлагается термины "очередь" и "триггер".
3) libfoo с новым soname, поступающая в incoming (и, естественно, прошедшая 
сборку в хешере), устанавливает триггер, по которому все собранные уже с ней 
пакеты ставятся в очередь, триггер снимается и эти пакеты проходят в основной 
репозитарий только после прохождения в этот репозитрарий самой libfoo.
4) Если какой-либо пакет зависит (в момент поступления в incoming) от двух или 
нескольких библиотек, находящихся в "режиме ожидания", то в очереди он будет 
нходиться, естественно, до тех пор, пока остаётся хотя бы один относящийся к 
нему триггер.

Сорри, если немного путанно, но ИМХО это как раз тот случай, когда "показать 
на пальцах" или "на картошке" (как В.И.Чапаев) проще, чем описать словами:)

-- 
Led.