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

[Alexey Tourbin]

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 пакетам,
которые увеличивают количество анметов)?
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/6823d7dc/attachment-0001.bin>