[devel-distro] вопросы и предложения по branding.git

[Michael Shigorin]

	Здравствуйте.
В процессе рассмотрения различных branding.git возникли следующие
соображения и вопросы -- просьба рассказать/прокомментировать,
чтоб наконец сбродиться, а не разбродиться (у меня интерес в виде
терминальных серверов и inquisitor).

Если какая часть письма непонятна -- проматывайте, читайте
следующую -- вдруг по ней найдётся что прояснить.  Они разные.

=== разминка ===

Существуют современные форки древних вариаций -- например,
branding-simply-linux.git происходит от древнего бранча lite,
сильно отличающегося по структуре от boyarsh/gnome-desktop и
boyarsh/master; предлагается по возможности перетаскивать их
содержимое в бранчи, являющиеся производными boyarsh/master,
с целью избежания трудоёмкости поддержки "дальнего форка"
в дальнейшем.

Здесь же наметилась необходимость выработки чётких понятий
(в контексте branding.git и mkimage-profiles-desktop.git)
_бренда_ и _флавора_ -- попытка как-то обозвать терминальный
вариант на базе Simply Linux, тривиальной не оказалась (разнобой
в строчках: slinux, simply, simply-linux, [gdm-theme-]simple).

=== conflicts "vs" alternatives ===

Наблюдаются концептуальные расхождения по (не)допустимости
одновременной установки аналогов ("conflicts vs alternatives"),
которые предлагаю сесть и выписать _применительно к брендингу_.

Мне кажется (в принципе, без привязки к реализациям), что:

- несколько полных комплектов разных branding в системе -- излишне;

- иметь _возможность_ установить несколько комплектов -- не страшно,
  если итоговый дизайн консистентен;

- обеспечить консистентность возможно:
  + либо простановкой односторонних конфликтов в полном объёме
    с созданием/применением робота для обновления списков в master,
  + либо применением/изобретением механизма для консистентного
    изменения ролевых симлинков сообразно используемому брендингу;

Из основных претендентов на платино-иридиевый branding.spec
на сейчас:

- вариант boyarsh/master не обеспечивает практической полноты
  проставления конфликтов;

- вариант zerg/master не обеспечивает консистентного
  использования master/slave alternatives для получения
  консистентного дизайна после обновления пакетов;

- оба эти варианта [после недавнего мержа] одинаково:
  + пользуются альтернативами для graphics,
  + принудительно устанавливают симлинки в %post
    для bootloader, bootsplash,
  + используют специфический способ в %post indexhtml,
  + грязно мухлюют в %post xfce-settings, 
  + ничего не делают в (отсутствующих) %post для alterator,
    release, notes, {kde4,kde3,gnome}-settings, slideshow,
    но содержат для них конфликты на другие варианты
    (по спискам, составленным вручную => устаревающим).

То есть говорить о консистентности не приходится, кроме как
сразу после установки системы.

=== наследование или полная замена? ===

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

Грубо говоря, полный дизайн "дорогой", а частичный всё равно
у нас сейчас подразумевает полный форк какого-либо из
существующих (что криво, больно и не WhiteLabel).

Крутятся мысли насчёт возможности чего-то вроде

branding-altlinux-5.1-graphics 5.1.0
branding-altlinux-terminal-kde3-settings 5.1.0 [кой-чего своего]

и также формирования license из набора темплейтов (сообразно
поставщикам, которых устраивают изложенные в шаблоне условия --
на сейчас знаю два примера, ООО Альт Линукс и Дениса Корявова,
при этом у меня уже есть правки и к en, и к ru по существу).

А ещё совсем не знаю, как это сформулировать -- но кажется,
что наличие кучи бранчей с кучей вариаций settings в каждом
является практически гарантией головной боли при выяснении
того, какие куски какого бранча не являются протухшими:
например, где сейчас поддерживаются kde3-settings,
чтоб отталкиваться от наименее древнего варианта?

В общем, тут пока чудится скорее нечто вроде branding-source-5.1
и возможности опереться на него в индивидуальных branding.git
для дистрибутивов на базе того же 5.1/branch.  Или не опираться,
если делается кастомный дизайн для кастомного дистрибутива.

-- 
 ---- WBR, Michael Shigorin <mike at altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/