WhiteLabel: различия между версиями

Материал из ALT Linux Wiki
м (→‎дизайн: s/design/branding/g и спрятал скорее устаревшее)
м (это не хлам, а тщательно окаменевшие древние записки!)
 
(не показано 18 промежуточных версий 2 участников)
Строка 1: Строка 1:
[[Категория:Devel]]
[[Категория:Mkimage]]
{{Historical}}


== ТЗ: white labeling ==
== ТЗ: white labeling ==
Строка 5: Строка 6:


=== intro ===
=== intro ===
Дистрибутивы ALT Linux появляются из профилей и пакетов при помощи утилит [[Mkimage|mkimage]] или [[Spt|spt]]; отличия вовсе не всегда оправдывают полновесный форк профиля.
Дистрибутивы ALT Linux появляются из профилей и пакетов при помощи утилит [[Mkimage|mkimage]] <s>или [[Spt|spt]]</s>; отличия вовсе не всегда оправдывают полновесный форк профиля.


В процессе разработки [http://git.altlinux.org/people/mike/packages/?p=mkimage-profiles-ltsp.git mkimage-profiles-ltsp] на базе [http://git.altlinux.org/people/boyarsh/packages/?p=mkimage-profiles-desktop.git mkimage-profiles-desktop] и наблюдения за пробным камнем на пути whitelabeling, а именно школьным проектом (где часть разницы и есть в смене дизайна и текстовых строк) -- начало формироваться понимание не только гибкости mkimage, но и желательности удобной схемы её использования для предотвращения непродуктивного форканья:
В процессе разработки [http://git.altlinux.org/people/mike/packages/?p=mkimage-profiles-ltsp.git mkimage-profiles-ltsp] на базе [http://git.altlinux.org/people/boyarsh/packages/?p=mkimage-profiles-desktop.git mkimage-profiles-desktop] и наблюдения за пробным камнем на пути whitelabeling, а именно школьным проектом (где часть разницы и есть в смене дизайна и текстовых строк) -- начало формироваться понимание не только гибкости mkimage, но и желательности удобной схемы её использования для предотвращения непродуктивного форканья:
Строка 26: Строка 27:
Это подразумевает также построение дерева ("водопада"?) требуемой для сборки информации -- от наиболее общей (тип дистрибутива) к частной (дизайн и мелкие особенности) с осмысленным наследованием значений по умолчанию частностями от общностей.  При этом дизайн/носитель определяются вместе постановкой задачи для дистрибутива; не уверен насчёт их порядка или вообще зависимости друг от друга.
Это подразумевает также построение дерева ("водопада"?) требуемой для сборки информации -- от наиболее общей (тип дистрибутива) к частной (дизайн и мелкие особенности) с осмысленным наследованием значений по умолчанию частностями от общностей.  При этом дизайн/носитель определяются вместе постановкой задачи для дистрибутива; не уверен насчёт их порядка или вообще зависимости друг от друга.


Предлагаемый порядок: DISTRO; FLAVOUR; DESIGN; MEDIA; набор FEATURE; DOCS.  Пример: DISTRO=Desktop, FLAVOUR=Lite, MEDIA=cd, остальное наследуется от предшественников (с заглавными буковками решено завязывать в пользу прописных).
[http://fly.osdn.org.ua/~mike/ALT/docs/whitelabel/whitelabel.PNG Предлагаемый порядок]: DISTRO; FLAVOUR; DESIGN; MEDIA; набор FEATURE; DOCS.  Пример: DISTRO=Desktop, FLAVOUR=Lite, MEDIA=cd, остальное наследуется от предшественников (с заглавными буковками решено завязывать в пользу прописных).


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


Следует также иметь в виду, что обычно собирается несколько образов за один проход -- например, <tt>live dvd rescue installer</tt>.  Было бы неудобно <tt>./configure; make; ./configure; make</tt>...
Следует также иметь в виду, что <s>обычно</s> иногда собирается несколько образов за один проход -- например, <tt>live dvd rescue installer</tt>.  Обычно <tt>./make-distro</tt> (один за раз).
 
'''Состояние:''' в [[Mkimage/Profiles/Desktop|m-p-d]] ужасное, переменные в огромном количестве и беспорядке снуют по всем этажам и отследить маршрут бывает сложно.  Похоже, стоит разделить создание хост-конфигурации (<tt>./configure</tt>), состава дистрибутива (<tt>make config</tt>) и собственно сборку дистрибутива (<tt>make image</tt>).


==== installer ====
==== installer ====
Строка 40: Строка 43:


При таком подходе возможно как выстроить схему зависимостей (например, <tt>installer-feature-ltsp-stage2 Requires: installer-feature-pxeboot-stage2</tt>), так и проставить конфликты между скриптами, которые производят несовместимые изменения в одном и том же конфигурационном файле.
При таком подходе возможно как выстроить схему зависимостей (например, <tt>installer-feature-ltsp-stage2 Requires: installer-feature-pxeboot-stage2</tt>), так и проставить конфликты между скриптами, которые производят несовместимые изменения в одном и том же конфигурационном файле.
'''Состояние:''' по большей части [[Installer/beans|сделано]].


==== mkimage-profiles ====
==== mkimage-profiles ====
Строка 49: Строка 54:
* поток информации по переменным от ключей configure и toplevel Makefile может быть излишне [странно] опосредован и таким образом хрупок (см. выбор <tt>INFO_NAME</tt>/<tt>INFO_LABEL</tt> в <tt>profiles/Makefile.in</tt> в зависимости от имени файла ISO на выходе);
* поток информации по переменным от ключей configure и toplevel Makefile может быть излишне [странно] опосредован и таким образом хрупок (см. выбор <tt>INFO_NAME</tt>/<tt>INFO_LABEL</tt> в <tt>profiles/Makefile.in</tt> в зависимости от имени файла ISO на выходе);
* <tt>configure</tt> знает слишком много о структуре профиля (<tt>profiles/*/Makefile.in</tt>).
* <tt>configure</tt> знает слишком много о структуре профиля (<tt>profiles/*/Makefile.in</tt>).
'''Состояние:''' mike@ начата работа над [[m-p|mkimage-profiles.git]], по состоянию на осень 2015 -- рабочий инструмент, которым штатно собираются [[starterkits]]/[[regular]].


==== пакетная база ====
==== пакетная база ====
В общих чертах определяется назначением и носителем дистрибутива; имеют место общие части (например, для любого livecd, любого xfce-based или любого школьного есть ряд обязательных пакетов) и специфичные (например, для 64-битного десктопа нет <tt>wine</tt> и <tt>mozilla-plugin-adobe-flash</tt>, а в Линукс Мастер нужно положить <tt>eclipse</tt>).
В общих чертах определяется назначением и носителем дистрибутива; имеют место общие части (например, для любого livecd, любого xfce-based или любого школьного есть ряд обязательных пакетов) и специфичные (<s>например, для 64-битного десктопа нет <tt>wine</tt> и опять нет <tt>mozilla-plugin-adobe-flash</tt>,</s> а в Линукс Мастер нужно положить <tt>eclipse</tt>).
 
<s>Также существуют мелкие, но важные различия между типичным составом списков для разных бранчей (e.g. M40/M41).  Их хочется уметь обрабатывать как "это общее, а это специфичное -- подхвати, что надо".</s> ''Похоже, для этого лучше подходят бранчи профиля -- слишком много изменений помимо списков пакетов.''
 
'''Состояние:''' так себе; в m-p-d:
* сделан хак под названием <tt>I586_ONLY</tt>, который на не-i586 превращается в символ комментария (<tt>#</tt>); бродят соображения то ли по условно-включаемым пакетам (<tt>?wine</tt>), то ли по тегам (где архитектура явно или перечнем отрицаний остальных поддерживаемых добавляется в список);
* написан скрипт <tt>bin/pkgdups.sh</tt>, ищущий дубликаты в списках пакетов -- но ими никто не занимается;
* написан скрипт <tt>bin/check-pkg-list</tt>, ищущий заведомо неустанавливаемые пакеты в списках -- но он не интегрирован в сборку удобным образом и потому также практически не используется.


Также существуют мелкие, но важные различия между типичным составом списков для разных бранчей (e.g. M40/M41).  Их хочется уметь обрабатывать как "это общее, а это специфичное -- подхвати, что надо".
В m-p не сделано никак особо, можно выкручиваться условным подцеплением списков по архитектуре.


==== брендинг ====
==== брендинг ====
Строка 69: Строка 83:
-->
-->


==== документация ====
NB: могут быть субварианты брендинга, как-то для LXDEsktop Lite/Standard (различные хайлайты пакетной базы).
Размышления аналогичны дизайну; предлагается <tt>docs-issue-$(DISTRO)_$(FLAVOUR)</tt> и <tt>alt-license-$(DISTRO)</tt> при отсутствии специфических пожеланий.


=== ссылки ===
=== ссылки ===
* [http://fly.osdn.org.ua/~mike/ALT/docs/whitelabel/ слайды] (kdissert, PNG)
* [http://fly.osdn.org.ua/~mike/ALT/docs/whitelabel/ слайды] (kdissert, PNG)
* [[Installer/beans|готовые компоненты инсталера]]
* [[Installer/beans|готовые компоненты инсталера]]
* [[Design|графический дизайн]]
* [[Branding|оформление дистрибутивов]]

Текущая версия от 14:05, 28 июня 2016

Small-pyramides.png
Архивная информация.
Описываемые в этой статье вещи больше не используются и оставлены только для обратной совместимости.


ТЗ: white labeling

intro

Дистрибутивы ALT Linux появляются из профилей и пакетов при помощи утилит 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. Обычно ./make-distro (один за раз).

Состояние: в m-p-d ужасное, переменные в огромном количестве и беспорядке снуют по всем этажам и отследить маршрут бывает сложно. Похоже, стоит разделить создание хост-конфигурации (./configure), состава дистрибутива (make config) и собственно сборку дистрибутива (make image).

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).

Состояние: mike@ начата работа над mkimage-profiles.git, по состоянию на осень 2015 -- рабочий инструмент, которым штатно собираются starterkits/regular.

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

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

Также существуют мелкие, но важные различия между типичным составом списков для разных бранчей (e.g. M40/M41). Их хочется уметь обрабатывать как "это общее, а это специфичное -- подхвати, что надо". Похоже, для этого лучше подходят бранчи профиля -- слишком много изменений помимо списков пакетов.

Состояние: так себе; в m-p-d:

  • сделан хак под названием I586_ONLY, который на не-i586 превращается в символ комментария (#); бродят соображения то ли по условно-включаемым пакетам (?wine), то ли по тегам (где архитектура явно или перечнем отрицаний остальных поддерживаемых добавляется в список);
  • написан скрипт bin/pkgdups.sh, ищущий дубликаты в списках пакетов -- но ими никто не занимается;
  • написан скрипт bin/check-pkg-list, ищущий заведомо неустанавливаемые пакеты в списках -- но он не интегрирован в сборку удобным образом и потому также практически не используется.

В m-p не сделано никак особо, можно выкручиваться условным подцеплением списков по архитектуре.

брендинг

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

NB: могут быть субварианты брендинга, как-то для LXDEsktop Lite/Standard (различные хайлайты пакетной базы).

ссылки