WhiteLabel
Материал из ALT Linux Wiki
м (→intro: fix spelling) |
м (→mkimage-profiles: remove broken links, fix the rest) |
||
Строка 43: | Строка 43: | ||
==== mkimage-profiles ==== | ==== mkimage-profiles ==== | ||
- | Наблюдаются следующие проблемы (на примере <tt>[http://git.altlinux.org/people/boyarsh/packages/?p=mkimage-profiles-desktop.git;a= | + | Наблюдаются следующие проблемы (на примере <tt>[http://git.altlinux.org/people/boyarsh/packages/?p=mkimage-profiles-desktop.git;a=summary mkimage-profiles-desktop]</tt> как наиболее развитого набора): |
* профили в силу своей нетривиальности размножаются методом клонирования и правки, при этом оригинал может "не ожидать" того стиля изменений, который производится, и не очень-то поддаваться <tt>git pull</tt>; | * профили в силу своей нетривиальности размножаются методом клонирования и правки, при этом оригинал может "не ожидать" того стиля изменений, который производится, и не очень-то поддаваться <tt>git pull</tt>; | ||
* сами профили могут иметь избыточность внутри: | * сами профили могут иметь избыточность внутри: | ||
- | ** например, сейчас разница между 18-строчными файлами <tt>base-{cd,dvd}/ | + | ** например, сейчас разница между 18-строчными файлами <tt>base-{cd,dvd}/Makefile.in</tt> составляет одну строку, которая опять же различается лишь отчасти, но для анализа изменений требует не только <tt>diff</tt>, но и глаз |
** см. тж. идентичные <tt>base-*/scripts.d/01-basesystem.manifest</tt> | ** см. тж. идентичные <tt>base-*/scripts.d/01-basesystem.manifest</tt> | ||
- | * поток информации по переменным от ключей configure и toplevel Makefile может быть излишне [странно] опосредован и таким образом хрупок (см. выбор <tt>INFO_NAME</tt>/<tt>INFO_LABEL</tt> в <tt>profiles/ | + | * поток информации по переменным от ключей configure и toplevel Makefile может быть излишне [странно] опосредован и таким образом хрупок (см. выбор <tt>INFO_NAME</tt>/<tt>INFO_LABEL</tt> в <tt>profiles/Makefile.in</tt> в зависимости от имени файла ISO на выходе); |
- | * <tt>configure</tt> знает слишком много о структуре профиля (<tt>profiles/* | + | * <tt>configure</tt> знает слишком много о структуре профиля (<tt>profiles/*/Makefile.in</tt>). |
- | + | ||
- | + | ||
==== пакетная база ==== | ==== пакетная база ==== |
Версия 21:49, 10 августа 2008
ТЗ: white labeling
Содержание |
intro
ALT Linux -- это название семейства дистрибутивов, создающихся из нестабильной ветки Sisyphus. Появляются они из профилей и пакетов при помощи утилит mkimage или spt. И отличия между дистрибутивами вовсе не всегда оправдывают полновесный форк профиля...
В процессе разработки mkimage-profiles-ltsp на базе mkimage-profiles-desktop и наблюдения за пробным камнем на пути whitelabeling, а именно школьным проектом (где часть разницы и есть в смене дизайна и текстовых строк) -- начало формироваться понимание не только гибкости mkimage, но и желательности удобной схемы её использования для предотвращения непродуктивного форканья:
- профилей (и целей сборки внутри них),
- инсталеров (и настроечных скриптов внутри них)
- и вообще фич вместе с багами в лучшей индусской манере copy-paste
(например, идентичные копии postinstall.d/06-pxe.sh присутствуют ныне в installer-{hpc,ltsp{,-school},junior} -- как их предполагается улучшать, если, скажем, сделаем control portmap server?).
По результатам предварительного обдумывания и обсуждения с boyarsh@, legion@, led@ решил написать с листов на столе не длинное письмо, а структурированную страничку.
цель ТЗ
Максимальная разумная ортогонализация профилей и инсталеров с тем, чтобы тратить время и силы на
- создание и улучшение стыкующихся компонент
а не на
- отслеживание багфиксов в тех git repo, которые когда-то клонировались,
- умножение бранчей на каждый чих отдела маркетинга (или свой) по части дизайна и см. п. 1, только с бранчами.
Попросту говоря, вместо 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 как наиболее развитого набора):
- профили в силу своей нетривиальности размножаются методом клонирования и правки, при этом оригинал может "не ожидать" того стиля изменений, который производится, и не очень-то поддаваться git pull;
- сами профили могут иметь избыточность внутри:
- например, сейчас разница между 18-строчными файлами base-{cd,dvd}/Makefile.in составляет одну строку, которая опять же различается лишь отчасти, но для анализа изменений требует не только diff, но и глаз
- см. тж. идентичные base-*/scripts.d/01-basesystem.manifest
- поток информации по переменным от ключей configure и toplevel Makefile может быть излишне [странно] опосредован и таким образом хрупок (см. выбор INFO_NAME/INFO_LABEL в profiles/Makefile.in в зависимости от имени файла ISO на выходе);
- configure знает слишком много о структуре профиля (profiles/*/Makefile.in).
пакетная база
В общих чертах определяется назначением и носителем дистрибутива; имеют место общие части (например, для любого livecd, любого xfce-based или любого школьного есть ряд обязательных пакетов) и специфичные (например, для 64-битного десктопа нет wine и mozilla-plugin-adobe-flash, а в Линукс Мастер нужно положить eclipse).
Также существуют мелкие, но важные различия между типичным составом списков для разных бранчей (e.g. M40/M41). Их хочется уметь обрабатывать как "это общее, а это специфичное -- подхвати, что надо".
дизайн
Предлагается переключать по --with-design= (умолчание наследуется от значения --with-distro или установленного в профиле). Затрагиваемые группы пакетов:
- alterator-design-*
- design-alterator-browser-* (маленькое исключение -- qt-junior)
- design-bootloader-*
- design-bootsplash-*
Реализация подразумевает добавление в 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) при отсутствии специфических пожеланий.
ссылки
- слайды (kdissert, PNG)
- Installer/beans