[sisyphus] Re: [POLICY] Sisyphus

[Dmitry V. Levin]

On Tue, Jan 27, 2004 at 05:44:00PM +0200, Michael Shigorin wrote:
[...]
> Попробую привести пример.
> 
> Сейчас:
> 
> * некий mike залил apache;
> * на следующий день оказалось, что в classic изменился apt и
>   теперь механизм учета неверсионированных зависимостей,
>   неверсионированно же удовлетворяемых в рамках репозитория
>   виртуальными пакетами, также изменился (вообще говоря, это
>   платформообразующее изменение -- то, что стоит упоминания
>   отдельной строкой в "По Граблям и Затем Обратно");
> * некий mike откатил старый хак и опять залил apache;
> * на следующий день выяснилось, что представления о
>   версионировании у rpm и perl не совпадают, причем каждый
>   по-своему прав; в итоге проблема углубилась, а dist-upgrade
>   пользователям mod_perl остается сломанным минимум третьи, а то
>   и четвертые сутки.

Просто у пакета mod_perl маленький вес.
Вот у libpango, например, вес гораздо больше был.

> При добавлении .incoming:
> 
> * некий mike залил apache;
> * на следующий день оказалось, что в рамках classic+incoming
>   apache-mod_perl сломан вышеуказанным образом;
> * [...выясняем, в чем дело...];
> * залита Правильная Сборка;
> * пролежав там свои N суток (неделю) и не обновившись, эта сборка
>   перемещается скриптом в свой .contrib или куда положено; при
>   этом пользователи нормального .classic этой бури в стакане не
>   ощутили.
> 
> Здесь около слов "оказалось" и "выясняем" можно сразу дописывать
> "поднимаем исключение <<ИЗМЕНА!!>>".

А что делать, если все сборки mod_perl не работают в текущем репозитарии?
Удерживать весь репозитарий или пожертвовать mod_perl'ом?  Кто будет
принимать решение?

Что ни говорите, но предложенная простая схема разбивается на
вышеприведённом примере.

> В идеале (tm) -- включает предыдущий пункт :) --
> 
> * майнтейнер apt объявил об изменении, которое задевает пакеты,
>   подпадающее под такие-то условия ("Provides: A" или "Requires: A"
>   без указания версии); как вариант -- это было обнаружено уже
>   postfactum _в_рамках_.incoming;
> * объявляется "точка перегиба", которая характеризуется:
>   - описанием происхождения и необходимости (последнее -- при
>     известности заранее) -- "начиная с apt-0.5.15cnc5-alt3, ...";
>   - тестом для проверки ее влияния на пакет ("$ .... .spec");
>   - типичным рецептом для типично ожидаемых проблем ("добавить
>     версию туда и сюда");
> * обнаружив, что эта точка задевает пакет apache, mike по крайней
>   мере не будет трепыхаться с лишней сборкой/залитием до тех пор,
>   пока не синхронизируется с Sisyphus/incoming+classic _после_
>   этой точки, а по обновлении будет иметь представление о
>   проблеме и способе решения;
> * после того, как это решение зафиксировано в пакете -- оно
>   попадает в .incoming, где лежит (исходя из того, что apache --
>   пакет важный, судя тому, что живет в .master, им пользуется 14%
>   пользователей Sisyphus, от него зависят 16 пакетов, etc, etc)
>   -- M1 дней, пусть трое суток.
> * после чего пакет apache-<версия>.alt<сборка>.src.rpm и его
>   бинарное потомство переселяются в компоненту master при
>   отсутствии новых точек перегиба, влияющих на них.

Ага, и всё это занимает полгода, в результате разработка Сизифа
оказывается парализованной. :(


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