[sisyphus] Re: [POLICY] Sisyphus

[Michael Shigorin]

On Mon, Jan 26, 2004 at 06:48:22PM +0300, info wrote:
> > > Сутки - мало!
> > Ну это "первая степень".  "Вторая" -- пресловутая неделя.
> Не должно быть этой "первой степени"!!! Мало кто  успеет
> обновиться, собраться и оттестироваться всего лишь за сутки. 

А на это никто и не закладывается.  Это минимальный интервал
между "обычными" обновлениями, которые скорее монотонны, чем
платформенные.

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

Так уже.

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

> > Кстати, по крайней мере какая-то информация по этой части для
> > mdk installer есть ("важно/неважно/прикольно").
> Субъективный взгляд, сильно зависящий от предметной области,
> где используется машина.

Бродят мысли по более многовекторному "взвешиванию" пакетов.

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

Да в общем понятно уже не первый год...

> > http://www.altlinux.ru/pipermail/community/2002-January/040036.html
> Теперь бы продолжить - для полного сизифа, да еще и постоянно 
> (или хотя бы периодически) обновляемый.

На моей домашней системе (~3G used на /usr, 1218 пакетов) rpmdot
отрабатывал что-то с полчаса и сравнимо -- собственно dot.  Огреб
PostScript на 2.7M, которым давится gv :]

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

Не дерево, а именно что граф.  И не kernel, а basesystem :)

> > Для удобства положил тот .ps сюда:
> > http://lrn.ru/~mike/rpmdeps.ps.gz
> Чего-то он у меня не открылся, точнее - пустой лист... 

Распакуйте его и/или поставьте mozplugger :)

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

Боюсь, на эту тему я говорить не сейчас не готов.

> Почему, к примеру, существуют отдельные группы "Офис" и
> "Издательство" - когда "издательские средства" есть часть
> офиса?

Усомнюсь, ну да ладно.

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

Кстати, /usr/lib/rpm/GROUPS в RH9 сильно похудел:
http://www.fedora.us/wiki/RPMGroups

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

Пока не вижу этой схемы ранжирования.

Есть вариант инициировать ее от раскладки по компонентам (и в
дальнейшем использовать _для_ этой самой раскладки) -- base,
kernel, ...

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

Ммм... в данном случае скорее из-за всяких libXft, чем XFree86.
Есть подозрение (не только мое), что это -- индикатор болезни не
KDE, а включения изменчивого (Xft) в разделенное протоколом
(X11).  Могу быть неправ.

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

Ugh.  Технологические вопросы еще как-то решаемы, вот с
административными, как показывает практиак, все куда хуже.

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

http://wiki.atmsk.ru/index.html/AltPolicy видели, кстати?

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

Ммм... про такую возможность не думал -- для меня он все же
daily.  На самом деле это [обычно] ничуть не страшно для
рассматриваемой темы.

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

Ну, в моей терминологии это *RPMS.incoming :)

[гм]

> Технически - я бы сделал как две отдельные директории на 
> сервере, одна под названием, например, sisyphusA, вторая 
> sisуphusB.
> 
> Далее, в момент обновления:
> {стоп доступу на оба сизифа}
> mv sisyphusA -> куда-нибудь в архив.
> mv sisyphusB -> sisyphusA
> {старт доступу на сизиф А}
> cp sisyphusA -> sisyphusB
> {старт доступу на сизиф Б}

Эту (подобную) схему для начала бы реализовать для собственно
синхронизации -- с тем, чтобы не получалось тянуть заливаемое.

С "отмашкой" по завершении, чтобы зеркалирующие скрипты
приступали к делу.

У меня на зеркале на время синхронизации в каталог выставляется
файловый флажок __SYNCING__ -- все хоть средство.

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

Думаю, с cp -l и его можно сократить.

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

В моей задумке -- _именно_ на ней.  Тут ключевой момент --
"непрерывность" платформы в течение TIME2.  Особые точки -- смену
gcc/glibc/... -- не продумывал толком вот только.  Отмашка за
TIME2 перед ними плюс неприем пакетов, собранных на сизифе до
"точки перегиба", после нее?

При этом для "точечности" есть четкие основания (вроде смены
soname у библиотеки или изменения поведения findreq) и не очень
(например, расширение набора дополнительных макросов,
предоставляемых "материнским" пакетом -- см. /etc/rpm/macros.d/).

Соответственно первое отлавливается и нотифицируется автоматом, а
вот второе -- дело майтнейнера пресловутого "м." п.  Ему, правда,
было бы удобнее не вылавливать всех майнтейнеров "клиентов"
своего пакета вручную, а черкнуть им всем сразу на какой
<pkg>@package-deps.altlinux.org.

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

Я к тому, что нет "полного сизифа" (или "полного debian").
Проверять же пакет кажется достаточным в той среде, которая
построена из basesystem + его зависимости.

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

(ну по крайней мере баги на них вешать можно)

Результаты apt-cache unmet при их критичности появляются в
devel на .

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

Напомнило тему "темп работы команды" в декабрьском devel на ... и
давнешнее обсуждение того, как развивалась mozilla до и после
определенного этапа, когда периодичность выпусков стала
планироваться и стабилизироваться -- в т.ч. вследствие
"притирания" команды и налаживания управления проектом.

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/