[Devel] Концепция дистрибутивостроения

[Evgeny Sinelnikov]

Здравствуйте,

Я уже довольно давно планирую составить некое обобщение своему видению
по созданию дистрибутивов... Далее я хочу подытожить этот момент.

Ставя задачу "сделать свой дистрибутив", можно подразумевать следующие варианты:
1) Сделать репозиторий, который будет поддерживать сообщество, на
основе которого будут делаться решения
2) Сделать свой репозиторий, который сам будет основан на уже
существующем, на основе которого будут делаться свои решения.
3) Сделать своё решение на основе существующего репозитория,
поддерживаемого сообществом.

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

Довольно длительный срок я вёл линию, что не стоит делать второй
вариант, что достаточно третьего... Но, к сожалению, практика
показала, что сидеть на бомбе, которая может взорваться, причём
неоднократно и не вовремя, крайне печально, а главное бьёт по
срокам...

В связи с этим было принято решение, в том или ином виде, организовать
свой репозиторий - Stable. Основывать его не базе веток (или бранчей),
которые поддерживает альтлинукс, как компания дело совершенно,
оказалось делом совершенно бессмысленным. Так что единственным
источником на основе которого стоит делать Stable остался Sisyphus,
чего и стоило ожидать.

В условиях поиска более технологичных, чем у альтлинукс, механизмов
поддержки стабильных бранчей была разработана следующая схема:
1) В начальный момент времени Stable создаётся из Sisyphus простым
копированием, сменой имён каталогов и генерацией баз apt.
2) Далее Sisyphus становится источником для обновления пакетов в
Stable. Обновление делается путём перекладывания групп взаимозависимых
пакетов. Предварительно группы создаются специальными утилитами как
разница между текущим содержимым Stable и более новым Sisyphus.
Процесс формирования групп, проверки их работоспособности, и
объединения в Stable позволяет аккуратно отвязаться от текущих проблем
разработки в Сизифе, сохраняя возможность вовремя обновлять устаревшие
пакеты с учётом зависимостей.
3) Процесс тестирования проходит постепенно и качественно зависит от
возможностей группы тестирования. Группа тестирования предположительно
может состоять от 1 до 5 человек, в зависимости от состояния
репозитория.
4) Процесс разработки интегрирован в процесс тестирования. Тестовые
репозитории представляют собой набор сборочных репозиториев - боксов
(boxes - /var/ftp/pub/Etersoft/LINUX на Etersoft/Boxes). Сборка в боксы
проводится с помощью специального сервиса geet-daemon из набора Gear
Etersoft. Сейчас тестовый вариант сервиса установлен на виртуальном
сервере geet. Предварительное описание можно найти здесь:
http://www.tartarus.ru/wiki/geet

Для полного внедрения этих механизмов необходимо завершить процесс
создания "утилит по перекладыванию из Сизифа"... На текущий момент
Вопрос подготовки к выставке приостановил реализацию этих утилит. Тем
не менее пересборка пакетов на Stable уже готова использованию.
Багфиксы направлять rlz@ в багзилу.

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

В связи с этим, наши решения делятся на два параллельных направления:
1) создание и поддержка своего репозитория (вариант 2)....
2) сборка расширений и обновлений для стабильных бранчей альтов.

Какие решения куда можно собирать?
1) Свои дистрибутивы... Включают наши фишки... их нужно создавать
новые, внедрять альтовые разработки ранее, чем они...
2) Расширять стабильные бранчи нашими фишками:
- wine
- tartarus
- сервер обновлений
В ряде случаев нужно решать компромисс относительно бекпортирования
пакетов в сами бранчи вместо расширения пакетов нашими...


Какие у нас есть фишки? Какие из них должны быть доступны в сизифе, а
какие исключительно коммерческие?
Это самый сложный для меня вопрос... Сейчас я думаю о том, что мы
может предоставить в дистрибутиве следующее:
- оптимизация под офисные задачи (их желательно сформулировать и
описать варианты поддержки)
- оптимизация по скорости (wks ядра от lakostis@, дело интересное, но
нам нужна поддержка железа, доп. модули, это нужно с ним тогда
обсудить), ускорение инитскриптов...
- дружелюбность установки наших пропиетарных пакетов... если есть
готовое, нужно взять из убунты или поднять наши наработки... хотелось
бы не универсализировать, а упростить задачу пользователя по
утстановке WINE на Etersoft... и всего дополнительного, что мы раздаём
через сайт...
- интеграция наших свободных решений в дистрибутив... CIFS на Etersoft
можно собрать прям в ядро, а можно и просто установить пакет
linux-cifs заранее...

Новое, которое мы готовим:
- сервер кеширования репозиториев
- утилита настройки списков репозиториев в apt (по умолчанию настроена
на работу по anacron)



-- 
Sin (Sinelnikov Evgeny)