Вход:  Пароль:  
FreeSource: TZ/AltLinux/WhiteLabel ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Эта страница была перенесена на altlinux.org. Текст на freesource.info заморожен.

ТЗ: white labeling

Оглавление документа

intro

ALT Linux — это название семейства дистрибутивов, создающихся из нестабильной ветки Sisyphus. Появляются они из профилей и пакетов при помощи утилит mkimage или spt. И отличия между дистрибутивами вовсе не всегда оправдывают полновесный форк профиля...


В процессе разработки mkimage-profiles-ltsp на базе mkimage-profiles-desktop и наблюдения за пробным камнем на пути whitelabeling, а именно школьным проектом (где часть разницы и есть в смене дизайна и текстовых строк) — начало формироваться понимание не только гибкости mkimage, но и желательности удобной схемы её использования для предотвращения непродуктивного форканья:

(например, идентичные копии postinstall.d/06-pxe.sh присутствуют ныне в installer-{hpc,ltsp{,-school},junior} — как их предполагается улучшать, если, скажем, сделаем control portmap server?).


По результатам предварительного обдумывания и обсуждения с boyarsh@, legion@, led@ решил написать с листов на столе не длинное письмо, а структурированную страничку.

цель ТЗ 

Максимальная разумная ортогонализация профилей и инсталеров с тем, чтобы тратить время и силы на

а не на


Попросту говоря, вместо git-fetch git.alt:/people/boyarsh/packages/mkimage-profiles-desktop master:desktop и последующего мержа (муторного, если мои и апстримные правки пересекаются) — охота делать хотя бы --with-installer=ltsp-school --with-design=ltsp-school, а когда-то — ./configure --with-distro=junior --with-features=ltsp,school :)


Это подразумевает также построение дерева («водопада»?) требуемой для сборки информации — от наиболее общей (тип дистрибутива) к частной (дизайн и мелкие особенности) с осмысленным наследованием значений по умолчанию частностями от общностей. При этом дизайн/носитель определяются вместе постановкой задачи для дистрибутива; не уверен насчёт их порядка или вообще зависимости друг от друга.


Предлагаемый порядок: DISTRO; FLAVOUR; DESIGN; MEDIA; набор FEATURE; DOCS. Пример: DISTRO=Desktop, FLAVOUR=Lite, MEDIA=cd, остальное наследуется от предшественников (с заглавными буковками решено завязывать в пользу прописных).


Или а-ля Rails: замена кучи перекладываний одного и того же набором договоренностей, «куда смотреть».

проблемы/предложения

data flow

Предполагается, что дистрибутивообразующим является назначение дистрибутива (PURPOSE); из него следует набор фич (FEATURE), к ним привязывается документация (DOCS). К этому всему идёт типовой или отдельный дизайн (DESIGN; см. тж. THEME). Из дизайна как такового ничего (пока) не следует.


Следует также иметь в виду, что обычно собирается несколько образов за один проход — например, live dvd rescue installer. Было бы неудобно ./configure; make; ./configure; make...

installer

Предлагается обдумать и произвести вынос часто используемых скриптов в пакеты с «фичами» инсталятора вида installer-feature-$(DISTRO)-$(FEATURE) для тех, которые могут иметь специфическое отношение к «кусту» инсталяторов (например, десктопных), или installer-feature-$(FEATURE) для наиболее общих и неинтрузивных фич. Например, пресловутый postinstall.d/06-pxe.sh просится в исходный пакет installer-feature-pxeboot и бинарный installer-feature-pxeboot-stage2.


При таком подходе возможно как выстроить схему зависимостей (например, installer-feature-ltsp-stage2 Requires: installer-feature-pxeboot-stage2), так и проставить конфликты между скриптами, которые производят несовместимые изменения в одном и том же конфигурационном файле.

mkimage-profiles

Наблюдаются следующие проблемы (на примере mkimage-profiles-desktop как наиболее развитого набора):


См. предлагаемый фрагмент Makefile верхнего уровня.

пакетная база

В общих чертах определяется назначением и носителем дистрибутива; имеют место общие части (например, для любого livecd, любого xfce-based или любого школьного есть ряд обязательных пакетов) и специфичные (например, для 64-битного десктопа нет wine и mozilla-plugin-adobe-flash, а в Линукс Мастер нужно положить eclipse).

дизайн

Предлагается переключать по --with-design= (умолчание наследуется от значения --with-distro или установленного в профиле). Затрагиваемые группы пакетов:


Реализация подразумевает добавление в profiles/base/Makefile.in::IMAGE_PACKAGES (параметризованных) имён либо пакетов, либо списков таковых (при этом внутри списка параметризации уже нет).


Первый способ обеспечивает гибкость на этапе сборки без модификации профиля: в параметрах configure можно передать произвольный суффикс — но ограничивает таковую по части полноты набора дизайна: все пакеты должны быть, а некоторые из них при этом недостаточно даже скопировать, поскольку этот же суффикс используется в имени каталога).


Второй способ позволяет класть частично адаптированный дизайн (например, design-graphics-ltsp-school, design-alterator-browser-qt-junior и alterator-design-desktop), а также не класть его вообще — но приводит к обязательности форка (части) профиля.


Таким образом, первый способ должен хорошо подходить для «серьёзного» подхода к делу, когда дизайн делается полным по определению, но менять его желательно с минимальными затратами времени; второй — для «домашнего», когда перекурочить профиль куда проще, чем возиться со всей стопкой дизайн-пакетов.


Здесь разумным компромиссом пока выглядит первый вариант с разумным fallback на заведомо существующий вариант дизайна и упакованные «пустышки» для дизайна с именем none на случай, когда таковой не требуется (пакет design-none, который Provides: всё (не)нужное).

документация

Размышления аналогичны дизайну; предлагается docs-issue-$(DISTRO)_$(FLAVOUR) и alt-license-$(DISTRO) при отсутствии специфических пожеланий.

ссылки


Страницы, ссылающиеся на данную: AltLinux/Sisyphus/SolutionProcess


 
Файлов нет. [Показать файлы/форму]
Комментарии [Скрыть комментарии/форму]