Re: [devel] создание Стабильного бранча и Национальной ОС

[Alexey Tourbin <at@altlinux.ru>]

On Mon, Oct 11, 2010 at 12:35:05AM +0400, Dmitry V. Levin wrote:
> On Sun, Oct 10, 2010 at 03:06:37AM +0400, Alexey Tourbin wrote:
> > Кажется, скоро придётся отфоркивать новый Стабильный бранч, вследствие
> > того, что необходимо создать Национальную ОС!  Для этого ещё нужно сделать
> > много дел.  Ниже список дел по моей части.  По-видимому, времени у нас
> > мало; хуже того, дела идут медленно.  Для осуществления задуманного мне
> > потребуются специальные административные полномочия (обход ACL при сборке
> > пакетов).
> 
> Обход ACL требует особого внимания: из самых лучших побуждений можно
> совершенно случайно что-то сломать или помешать мейнтейнеру.

С обходом ACL я собираюсь выполнять только ограниченные действия,
которые преследуют определенную цель.  В некоторых случаях это просто
полуавтоматическая пересборка пакета для обрастания зависимостями.
В некоторых случаях надо дополнительно отключить symbol versioning.

> > Последние трое суток сборочница парализована из-за очень больших заданий
> > с qt4 и kde, а теперь и gnome.  По-видимому, потребуются ещё
> > дополнительные полномочия срубать неугодные мне задания.-)
> 
> Может, лучше договориться с людьми?  Я думаю, что ради всеобщего блага они
> пойдут навстречу.

Ну да, про срубание заданий это уже очень круто, поэтому я поставил
смайлик.  Хотя всё-таки защёлка в виде 'AWAITING [locked]' иногда
практикуется.

> > 1) Пересборка библиотек с set-versions.  Надо пересборать достаточно
> > большой набор библиотек, чтобы у них появились set-version provides.
> > Тогда впоследствии не придётся пересобирать пакеты, слинкованные
> > с этими библиотеками (чтобы у этих пакетов появились set-versioned
> > requires).
> 
> Это очевидно, хотя в некоторых случаях лучше сразу собрать более свежие
> версии библиотек.

Пока мы собираем более свежую версию библиотеки, прошли уже 10 пакетов,
которые слинковались со старой библиотекой и не обросли зависимостями.
Значит, вместо того, чтобы лишний раз обновить один пакет (библиотеку),
придется потом пересобирать 10 пакетов.  Хотя это не настолько просто,
пакеты потом всё равно придётся пересобирать.  Но в первом приближении
быстро пересобрать библиотеки смысл есть.

> > Кроме того, у всех библиотек надо оторвать наши самодельные
> > versioned scripts - их функция теперь перекладывается на set-versions;
> > а также отрывание version scripts улучшит совместимость альтовских
> > бинариков с не-альт lsb средами.
> 
> Это спорно.  Наши самодельные versioned scripts лучше всего заапстримить
> ко всеобщей пользе.  По крайней мере, мне это иногда удавалось.

По-моему, symbol versioning глобально не прижился.  И если за последние
несколько лет в этом направлении было удивительно мало движений, то мы
сейчас не сделаем погоды.  Вот два относящихся к делу соображения.
1) У symbol versioning компромиссный и уродский дизайн: неверсионированный
символ может разрешаться в версионированный, а версионированный -
в неверсионированный.  Казалось бы, неужели такое возможно?
2) Скрипты надо делать очень аккуратно вручную, и желательно понимать код
и логику релиз-процесса.  Например, у нас есть самодельный интерфейс
GLIB_2.15.6.  Но это была последняя бета-версия перед релизом 2.16,
так что надо было набивать интерфейс GLIB_2.16 (которого у нас нет).
Но на стадии 2.15.6 ещё не было понятно, каким будет окончательный набор
новых символов в 2.16.  Это очень хрупкая конструкция, я сам несколько раз
облажался когда делал version scripts.  Короче, я бы за наши version
scripts не поручился.  А в этот скрипт не возьмут просто по причине
GLIB_2.15.6.

> > 2) perl-5.12.2 - в основном собран.  Надо ставить запрет на perl-5.8
> > и набивать таск.  На первом этапе надо пересобрать архитектурно-зависимые
> > пакеты в количестве примерно 300 штук.
> > 
> > Основное отличие - от perl-base оторваны подляторы (perl-Pod-Parser,
> > perl-podlators и т.д.), а при сборке перловых пакетов man-страницы
> > по умолчанию генерироваться не будут.
> 
> Некоторые люди по разным причинам любят man-страницы.  Для того, чтобы они
> не страдали от того, что одни мейнтейнеры пакуют их, а другие рекомендуют
> использовать perldoc, хорошо бы запаковать пакет с файлтриггером.  Кому
> нужны автосгенерированные man-страницы, тот сможет установить этот пакет и
> получить их все.

Триггер можно запаковать потом (к тому же основная его часть уже написана,
просто там вместо триггера стоит cronjob), а мигрировать на перл надо
сейчас.  А то не успеем собрать Национальную ОС!

Кстати, вопрос по триггеру, что он должен делать по файлам?  cronjob
складывает генерат в /var/cache/perlman и расставляет/удаляет симлинки
в /usr/local/man.