[sisyphus] [POLICY] Sisyphus

[info]

23 Январь 2004 18:13, Michael Shigorin написал:
> On Fri, Jan 23, 2004 at 05:01:30PM +0300, info wrote:
> > Так это вопрос администрирования репозитария, и вопросы
> > вообще-то к руководству ALTа.
>
> Ээээ... это та самая "полиси дистрибутива".  Неуловимая
> материя, витающая в головах -- которую надо поймать и
> зафиксировать.
>
> > Вывод: нужен дискретный фиксаж по времени (понятие "версия"
> > все-таки не зря выдумано:-)).
>
> Он есть -- одни сутки.  Вот только каналы не резиновые на
> всем пути от rsync.altlinux.ru до каждого пакаджера.

Сутки - мало! Считайте сами: где-то рабочий день займет 
обновление своей машины до текущего сизифа, с учетом времени 
закачки всех пакетов, а также того, что после обновления 
желательно еще и посмотреть, не сломалось ли чего... Второй 
рабочий день - сборка, если ее делать качественно и не спеша, и 
тем более - если пакетов несколько (а такие вещи как KDE - 
сколько там пакетов???) Третий день - тестирование собранного, 
и слив собранных пакетов. Получаем minimum minimorum для кванта 
времени - трое суток. 

>
> Поэтому по крайней мере я слышал и другой интервал --
> "принимаются пакеты, собранные на Sisyphus не более чем
> недельной давности".

"Слышал"... :-((( Такие вещи должны быть чугунными буквами 
написаны в правилах для упаковщиков.

>
> > Разумеется, период времени между обновлениями репозитария
> > должен быть не такой большой, как у "больших" версий, но он
> > все-таки какой-то период стабильности (неделя, к примеру)
> > должен быть, чтобы дать упаковщикам время собирать свои
> > пакеты все-таки на одной и той же базе.
>
> Ну это скорее всего относится к тем изменениям, которые
> ощутимо меняют Sisyphus как _платформу_.
>
> > Вообще-то, это большая работа, над этим надо думать, и вот
> > так просто в одном письме рецепта-панацеи не дать...
>
> Да, конечно.
>
> Поможете думать?

Ну давайте смотреть.

Прежде всего, необходимо ранжирование пакетов по категориям 
важности. Ясен день, что glibc или gcc - это категория A, XFree 
- категория B, а какая-нибудь dia или мой любимый qcad - это 
самая низшая категория важности. Новый glibc существенно меняет 
сизиф как платформу, а новый qcad - совсем не меняет...

Строго говоря, кому-то из ALTа надо не пожалеть времени и 
нарисовать здоровую, на всю стенку, иерархическую блок-схему 
(дерево) пакетов и их зависимостей. тогда уровни важности сами 
будут видны из топологии. Кстати же, эта схема вообще поможет 
проектировать дистрибутив.

Для ранжирования удобно использовать механизм групп в rpm. 
Сейчас пакеты делятся по группам как-то странно, вроде бы с 
точки зрения их предназначения (функциональности), а с другой 
стороны - и вроде как нет... Никаких четких пракил, в какую 
группу какой пакет относить, нет. Следствие: механизм групп не 
сильно используется. 

К ранжированию надо прикрутить автооповещение. То есть, если 
обновился пакет какой-то категории важности, то упаковщики 
пакетов низших категорий должны получить письма с извещением о 
необходимости пересобрать пакет в новом окружении.

И здесь же - оповещение о планируемом изменении пакетов. То 
есть, как только упаковщики того же glibc определяют, когда они 
по графику наметили выложить новую версию, то они должны 
оповестить всех остальных, чтобы остальные не делали лишнюю 
работу.

Далее, четко разделить: сизиф А и сизиф Б. Сизиф А - это то, что 
лежит в репозитарии, доступно для скачивания, и на основании 
чего собираются пакеты. Сизиф Б - это то, куда кладутся новые 
пакеты, но что недоступно для скачивания до истечения кванта 
стабильности. В начале кванта стабильности содержимое сизифов А 
и Б полностью идентично, по мере появления новых пакетов сизиф 
Б все дальше уходит от сизифа А, наконец квант стабильности 
кончается - доступ к Сизифу А блокируется, сизиф А обновляется 
до сизифа Б, далее сизиф А разблокируется - и все по новой. 
Видимо, так оно есть и сейчас, но как-бы в не очень явном виде.

Далее, на входе в репозитарий нужна автопроверка зависимостей. В 
ALTе должна стоять машина с ПОЛНЫМ установленным текущим 
сизифом. И как только появляется новый пакет (или группа 
пакетов) - должна проводиться попытка их установки. Это легко 
делается даже в автоматическом режиме, соответствующий скрипт 
написать нетрудно. Обновлять не через apt (это ведь НЕ 
обновление ИЗ репозитария, а обновление САМОГО репозитария 
нет...) а тупо, rpm -Uhv {чего поступило от упаковщика}. Если 
установка прошла нормально - прибывшие пакеты идеут в сизиф Б. 
Если нет - заворачиваются, а сборщик получает соответствующее 
письмо.

То есть получается, что имеем: "выходной репозитарий" с сизифом 
А, потом "входной репозитарий" с сизифом Б, который недоступен 
для скачивания до истечения кванта стабильности, и параллельно 
- тестовая машина, плавно обновляемая синхронно с сизифом Б.

Вот пока что пришло в голову...