Re: [devel] Стабильный Сизиф II

[Anton Farygin <rider@altlinux.com>]

Fr. Br. George wrote:
> On Wed, Aug 23, 2006 at 03:41:01PM +0400, Alexey Tourbin wrote:
>> 1) Дождаться нового toolchain'а, в котором будет -D_FORTIFY_SOURCE
> Насколько это её улучшит в плане стабильности?
> 
>> 2) Повысить пересобираемость сизифа.  Последняя плановая пересборка была
>> 9 июля, и сейчас мы даже не знаем, какие пакеты у нас собираются, а
>> какие нет.
> Разумеется. Сейчас ведутся работы по восстановлению регулярности пересборок.
> 
>> 3) Синхронизация i586 и x86_64, если выпуск предусматривает поддержку
>> последней платформы.  Это тоже немалый объем работ, который может занять
>> несколько месяцев.
> Выпуск нужен в этом году. Пока по x86_64 ситуация такая: если установщик
> будет поддерживать x86_64, будет и выпуск на x86_64, состоящий из
> собирающихся пакетов. Не думаю, что в ближайший год мы сможем
> организовать эффективное _тестирование_ сколь-нибудь обширной пакетной
> базы на x86_64. Какой-то минимум оттестирован будет.

1) Программа установки не зависит от используемой архитектуры.. под 
какую архитектуру её соберёшь - под такой она и будет работать.
2) Эффективное тестирование x86_64 для серверов - вполне реально, и 
насколько я знаю - уже ведётся. Для рабочих станций это вообще запросто 
- я уже почти 8 месяцев работаю на десктопе с x86_64 и 
рассинхронизированным сизифом. Из прсоблем - только вопрос с 
синхронизацией x86_64 и i586 пакетной базы.

> 
> Про "рассинхронизацию" i586 и x86_64 поподробнее можно?

Посмотрите архив списка рассылки incominger на предмет того, какие 
пакеты собрались для i586, но при этом не собрались для x86_64. И 
причину reject'а.

Говоря более коротко:
python и много в gnome нужно чинить. Очень много пакетов собирается без 
проблем для i586 и не собирается для x86_64. Об этом же говорит и 
количество unmet'ов для x86_64.

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

Заморозка возможна, если незамедлительно принять меры как минимум к 
синхронизации двух архитектур (я писал о необходимых мерах полгода 
назад) + довести до ума как минимум те пакеты, которые кардинально 
влияют на установку системы. Для последнего - необходимо в ближайшее 
время собрать ISO образ минимального инсталятора и составить список 
вылезших проблем.

Из того, что помню:
- нет установки загрузчика после второй стадии, ибо udev в чруте не 
работает, а устройства отсутствуют. Потенциальное решение - использовать 
  mount --bind или mount --move для /dev/ в чрут с установленной 
системой. Но это надо экспериментально провертья
- apt-cdrom не умеет работать с HAL, в итоге установка пакетов на 
третьей стадии невозможна без наличия /media/cdrom. Решение в виде 
создания /media/cdrom не подходит, ибо вылезет всё та же проблема с 
двумя приводами
- нет нового design-bootloader-<продукт> для нового syslinux/gfxboot. 
Здесь просто нужно садится и делать. По срокам - примерно две недели с 
учётом наличия готового дизайна. Отказываться от gfxboot нереально, ибо 
на него завязаны кусочки первой, второй и третьей стадии инсталятора (по 
моему всё-таки третья не завязана, но надо разбираться).

Это то, что вспомнилось из Major. Всё остальное вылезет при сборке ISO 
образов (минимальный, максимальный, средний (Compact)).

Максимальный образ необходим для проверки функционала установки пакетов 
с учётом конфликтов. Под максимальным образом подразумевается весь 
Sisyphus за исключением unmet'ов. Минимальный образ необходим для 
ускоренния тестирования базовой системы/поддержки железа, средний образ 
- для проверки функционирования поддержки железа в реальной жизни и для 
проверки пакетной базы Compact'а (KDE/OpenOffice и их взаимодействие с 
остальными компонентами системы)

Rgds,
Rider