[sisyphus] Re: [POLICY] Sisyphus

[info]

26 Январь 2004 17:20, Michael Shigorin написал:
> On Mon, Jan 26, 2004 at 12:39:41PM +0300, info wrote:
> > > > Вывод: нужен дискретный фиксаж по времени (понятие
> > > > "версия" все-таки не зря выдумано:-)).
> > >
> > > Он есть -- одни сутки.  Вот только каналы не резиновые на
> > > всем пути от rsync.altlinux.ru до каждого пакаджера.
> >
> > Сутки - мало!
>
> Ну это "первая степень".  "Вторая" -- пресловутая неделя.

Не должно быть этой "первой степени"!!! Мало кто  успеет 
обновиться, собраться и оттестироваться всего лишь за сутки. 
Упаковщий должен иметь _достаточный_ и вдобавок заранее 
известный ему период времени, относительно которого он уверен: 
за этот период окружение не изменится.

>
> > Третий день - тестирование собранного, и слив собранных
> > пакетов. Получаем minimum minimorum для кванта времени -
> > трое суток.
>
> На самом деле и между ними могут быть задержки.  Но в общем
> -- неделя :)

Да, оптимум - неделя. 

>
> > Прежде всего, необходимо ранжирование пакетов по категориям
> > важности.
>
> Кстати, по крайней мере какая-то информация по этой части для
> mdk installer есть ("важно/неважно/прикольно").

Субъективный взгляд, сильно зависящий от предметной области, где 
используется машина. Для кого-то apache важен, мне вот - 
совершенно нет. А уже не раз поминавшийся qcad для меня - 
основной рабочий инструмент, тогда как очень и очень многим он 
совершенно без нужды. 

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

>
> > Строго говоря, кому-то из ALTа надо не пожалеть времени и
> > нарисовать здоровую, на всю стенку, иерархическую
> > блок-схему (дерево) пакетов и их зависимостей. тогда уровни
> > важности сами будут видны из топологии. Кстати же, эта
> > схема вообще поможет проектировать дистрибутив.
>
> Вообще это уже делалось:
>
> http://www.altlinux.ru/pipermail/community/2002-January/04003
>6.html

... графическое отображение зависимостей в минимальной
системе, построенной на базе ALT Linux Sisyphus (от 5 
января)....

Судя по аннотации - первый маленький шажочек в правильном 
направлении.

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

Получается же классическое дерево, сиречь - граф. В корне, на 
нулевом уровне - kernel, и дальше от него пошло ветвиться.

>
> Для удобства положил тот .ps сюда:
>
> http://lrn.ru/~mike/rpmdeps.ps.gz

Чего-то он у меня не открылся, точнее - пустой лист... 

>
> См. тж. apt-cache(1) по поводу dotty.  Оно без учета
> важности, и не факт, что _из_ нее надо исходить -- а не
> считать ее как сумму зависимостей от данного пакета в
> каком-то виде.

Не знаю, можно ли оценивать важность алгебраическим методом, как 
сумму зависимостей (если правильно понял)... Важность скорее 
вытекает из топологии пакетов. 

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

Полностью согласен. Нынешнее разбиение, мягко скажем, несколько 
удивительно. Почему, к примеру, существуют отдельные группы 
"Офис" и "Издательство" - когда "издательские средства" есть 
часть офиса? А почему TeXmacs - вообще в "Редакторах", а LYX 
вместе с самим Tex - в "Издательство"? Ну и так далее, и тому 
подобное.

Результат - понятие "группы" на практике использовать крайне 
затруднительно. Непонятно, где что искать. Это понятие и не 
используется de-facto. 

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

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

Причем - важный момент - та схема, о которой я говорю, вовсе не 
означает, что между пакетами разных уровней непременно должна 
быть прямая зависимость. Тот же KDE будет, в общем случае, 
работать на самых разных версиях того же Xfree. Но если 
обновился XFree - (а тем более glibc) - то полезно пересобрать 
KDE. Так сказать, во избежание....

Так что речь не о зависимости в программистском смысле слова, а 
о зависимости, так сказать, в административном. 

>
> > И здесь же - оповещение о планируемом изменении пакетов. То
> > есть, как только упаковщики того же glibc определяют, когда
> > они по графику наметили выложить новую версию, то они
> > должны оповестить всех остальных, чтобы остальные не делали
> > лишнюю работу.
>
> Да.
>
> > Далее, четко разделить: сизиф А и сизиф Б.
>
> Это как-то тяжко.  Лучшее, что пришло в голову по этому
> поводу -- изложил не так давно в devel@ :
>
> http://altlinux.ru/pipermail/devel/2003-November/033007.html

Не сказал бы, что очень тяжело, но в чем-то с Вами согласен. 

Смотрим целевые аудитории пользователей Сизифа:

1. Разработчики и упаковщики;
2. Продвинутые пользователи вроде меня, равно как и "пионэры", 
которые сами пакетов не собирают, но которые по каким-то 
причинам не хотят пользоваться стабильными дистрибутивами.

Отсюда политика:

"сизиф А" - это тот сизиф, который есть на сегодняшний день, 
только обновляемый жестко раз в неделю (скажем, в ночь с 
пятницы на субботу).
"сизиф Б" - это тоже практически тот же самый сизиф, что и 
сегодня, а который заливаются пакеты по мере поступления 
поступления, но к которому имеют доступ _для_скачивания_ только 
упаковщики; причем для упаковщиков особо оговаривается, дабы 
они старались собирать свои пакеты на "сизифе А", а новые 
пакеты из "сизифа Б" брали только если уж край и без них 
никуда.


Иными словами, надо функционально разделить обновление системы 
пользователями (в т.ч. упаковщиками) и обновление самого 
сизифа. 

В военном деле эта штука называется "перекат". Опишу, как это 
делается - вдруг кого-то мысль, по аналогии, посетит? Итак, 
работают тройки. Один лежит и прикрывает остальных огнем. 
Второй делает перебежку. Третий в это время переползает от 
места падения. Закончив переползание, он открывает огонь. 
Строго в этот момент второй падает и начинает переползание, а 
первый прекращает огонь и начинает перебежку. И так по 
кругу....

Не знаю, может и здесь стоит подумать о "тройках"... Но пока 
говоримс о "двойках"

Технически - я бы сделал как две отдельные директории на 
сервере, одна под названием, например, sisyphusA, вторая 
sisуphusB.

Далее, в момент обновления:

{стоп доступу на оба сизифа}
mv sisyphusA -> куда-нибудь в архив.
mv sisyphusB -> sisyphusA
{старт доступу на сизиф А}
cp sisyphusA -> sisyphusB
{старт доступу на сизиф Б}

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

А если еще явно указывать пользователям - "до обновления 
осталось столько-то времени" - то они и сами решат, стоит 
запускать обновление из сизифа А за 5 минут до обновления 
самаого сизифа, или нет :-)))

>
> т.е. отдельная компонента Sisyphus, которая:
>
> - принимает в себя свежезалитые пакеты наиболее оперативно;
> - рекомендована к применению разработчиками;
> - дополнительно тестируется опытными пользователями.

Вот это и есть сизиф Б, с той только поправкой, что сборка новых 
пакетов идет, _как_правило_, не на нем, а на сизифе А.

>
> При этом цена перебрасывания пакета в e.g. contrib или base
> -- переброс симлинка, а не перетягивание пакета заново.
>
> > Далее, на входе в репозитарий нужна автопроверка
> > зависимостей.
>
> Она и есть.
>
> > В ALTе должна стоять машина с ПОЛНЫМ установленным текущим
> > сизифом.
>
> Это невозможно по очевидным причинам (Conflicts:).

Вы имеете в виду конфликты между файлами разных пакетов - как, 
например, lesstiff и openmotif? Ну, надо подумать... Десяток 
машин ставить негоже, дороговато будет, а вот несколько 
chrooted вариантов сизифа на одной мощной машине - почему бы и 
нет?

>
> > Если нет - заворачиваются, а сборщик получает
> > соответствующее письмо.
>
> Эээ... а Вам QA Team Robot не пишет душевные письма, да? :-)

Нет. Я не упаковщик :-))) Но с пакетами из сизифа, у которых 
неразрешенные зависимости - дело при установке имел-с... :-(((

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

Все правильно.

Цикл жизни сизифа:

- обновление упаковщиком своей машины из сизифа;
- компиляция своих пакетов;
- обновление самого репозитория.

По сути, ведь это та же последовательность, что и выполнение 
команд процессором. Только там: загрузка данных в регистры, 
выполнение команды, запись результатов. Представьте себе, что 
бы было, если бы в середине выполнения, скажем, команды 
сложения могло бы изменяться содержимое регистров данных, 
хранящих слагаемые...

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



>
> 2 inger: так как насчет RPMS.incoming?  Со скриптом для
> перекладывания через неделю, для начала?
>
> 2 mithraen: руки до этих самых скриптов не дошли?