[devel-distro] I: Lite for 4.1 и проблемы инфраструктуры

[Michael Shigorin]

On Sun, Nov 16, 2008 at 11:23:48PM +0300, Eugene Prokopiev wrote:
> > > А хотелось бы вынести дефолты DM/DE, шрифтов (а может и группы
> > > ПО?) в локальные настройки
> > Ну так вынеси и обеспечь наличие варианта, не изменяющего
> > ничего относительно текущего состояния.
> Дык перепиливать все надо ...

Думаешь, я не перепиливал? ;-)  И ещё много осталось, причём
сперва попробовать, потом отстраниться и подумать, потом уже
перепиливать.

Это удобней делать в межсезонье, когда никто параллельно не
воротит те же самые куски.  Вот сейчас может быть ещё некоторое
время относительно удобно трогать master, пока изменения идут 
по большей части в m-p-d::4.1.

Так что дерзай :-)

> Нужно сначала договориться о том, какие группы пакетов бывают

Ну так давай.  Причём это можно и коммитами предлагать.
И ещё есть предположение, что группы уже пора складывать
в иерархию (этому ничто не мешает).

> и о правилах именования этих групп. В голову приходит:
> 1) basesystem без Х (но с поднятым по дефолту sshd)

IMHO sshd -- ни разу не basesystem, скорее interactivesystem
или лучше ещё как.  Или man тоже в basesystem?

> 2) Xorg c драйверами (+ fake WM в виде xterm, что ли) и шрифтами

А там нужен wm по зависимостям?  В xinitrc был фолбэк на xterm.

> 3) разные простые WM (wm-icewm, wm-openbox и т.д.) с окружением (для
> openbox, например, это будет obconf и неопакеченный еще у нас obmenu)

Ну так это вообще не нуждается в согласованиях поштучно -- бери
да делай.  Тут разве что packages-lists/ сделать неплоским
каталогом да пройтись по упоминаниям списков в субпрофилях.
И тогда переименовать в wm/openbox или desktop/openbox.

> А вот дальше хуже, т.к. пошло прикладное ПО, и тут у разных
> дистростоителей могут быть сильно разные предпочтения вплоть до
> того, что тебе нужен украинский, а мне -- нет.

Точнее, дистр с большей претензией на универсальность имеет
больше таких проблем.  Но в принципе пока можно на них не сильно 
заморачиваться, а в будущем копать в сторону --with-languages
(вместо одного --with-language) и более умной генерации
соответствующих списков.

Для этого была бы сильно полезна фича вида "возможно, такой вот
пакет" -- когда kde-i18n-ZZ может быть, а вот k3b-i18n-ZZ может 
и не оказаться.  Ну или bin/existor можно применить приямщас --
см. 3f8878e86e3ce2b31e731ac1ec38857b8ac1ff17 в m-p-d (скриптик
родом из 5be05a16e1233eb8ec27b9dd111cd64a6f1a2c94).  Только это
перечисление руками получится, а не генерация "feeling lucky".

> Но группы нужны, пусть даже они будут называться
> enp-favorite-apps.

Сделай пока подкаталог enp/ и туда? :)

> Это кажется очевидным, но сейчас недостаточно последовательно
> соблюдается - см. kde-lite.in или xfce-in.

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

Видишь некрасивость -- придумай и сделай красиво.

> Да, группы могут быть полезны не только для того, что будет
> установлено, но для stage2 - мне там бывают нужны разные sshd :)

Мне тоже, но пока обломался.  Причём даже не могу вспомнить репо,
в котором был соответствующий бранч -- если тоже обломаешься
совсем, могу ещё в переписке поискать (то ли с ldv@, то ли
с boyarsh@ вроде была).

> Вопрос еще в том, что должны представлять из себя эти группы:
> файлы в профиле, как и сейчас, или пакеты по аналогии с
> installer-feature-* с зависимостями. Последнее вроде более
> громоздко, но позволит вынести группы пакетов в локальную
> конфигурацию, т.е. сказать:

У каждого из этих вариантов есть проблемы и неудобства.

Метапакеты позволяют зависимости и конфликты (в т.ч.
версионированные), но цикл их изменения заметно дольше
и больше отвлекает даже при локальном репозитории, а уж
если сборки делаются строго на бранче -- то клеим ласты.

Проходил во времена выпекания дистрибутивов в sandman
с использованием дистрообразующего пакета.

> ./configure --with-stage2=desktop-installer,debug-tools
> --with-result=basesystem,xorg,-dm-gdm,wm-openbox,enp-office-tools

Повторюсь, если ты в прошлый раз не заметил: я считаю ошибкой
выносить столь низкий уровень в ключи configure, поскольку это
неосмысленная гибкость на столь высоком уровне и породит именно 
то, что тебе выше будто не нравилось ("возврат к spt").

Вообще то, что у нас сейчас переменные шуруют из toplevel
в скрипты субпрофилей напрямую -- это проблема, которая вовсю
вылезла при попытке порефакторить такую однослойную кашу в
"водопад" -- когда на верхнем уровне можно задать ТУ, на уровне 
profile/ вырисовывается ТЗ, а уж ниже идёт его реализация.

mkimage умеет шибко гибко (как хороший инструмент), но вовсе не
обязательно этим злоупотреблять в профиле -- скорее наоборот:
это место для упорядочивания.

> Далее. Группы -- это не все, нужны также:
> а) хаки -- для них есть удачное решение в виде
> installer-feature-*, но плохо их жесткое прошивание в
> инсталлере.

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

> В итоге я не могу по-человечьи собрать десктопный дистрибутив
> с включенным по дефолту ssh.

Значит, с тебя придумать реализацию переключателя, а никакой
проблемы в том, чтоб i-f-* туда посмотрели -- не вижу.

IMHO так (с прицелом на сведение профилей):

--with-distro=server (и производные)
`-> по умолчанию включается sshd, но можно и выключить

--with-distro=desktop (и производные)
`-> по умолчанию выключается sshd, но можно включить

--with-remote=yes
`-> включать удалённое управление добавленным

Попробуй думать про ключи configure как про теги дистрибутива,
которые в идеале могут быть более или менее точными.  Например,
"тег" distro=desktop является менее точным, чем "тег" distro=
desktop-business или сочетание distro=desktop flavour=lite.
Где-то так.

(или лучше сразу смотреть на текущую сборочную инфраструктуру
ядра по части make menuconfig? :)

> Было бы неплохо иметь предопределенные features в инсталлере,
> которые можно включать/выключать так:
> ./configure --with-installer-features=-one,+two

Повторюсь, сами по себе текущие пакеты i-f-* я считаю слишком
низким уровнем, чтобы выносить в ключи configure.

Это сознательное решение, поскольку маленькие фичи, которые можно
задействовать в своих мегафичах -- более реальны с точки зрения
совместной разработки (помнишь кучу копий 06-pxe.sh по половине
installer-$distro?).  Но при этом неудобны в непосредственном
поштучном применении для целей конфигурации дистрибутива -- это
гвоздики в доме.

> Да, features могут быть привязаны не к инсталлеру или профилю,
> а к группам пакетов - вот еще один аргумент в пользу оформления
> этих групп именно в виде rpm-пакетов.

Могут, но тут лучше подумать о том, что является носителем такой
конфигурации и кто её изменяет (и какой ценой) -- репозиторий или
профиль.  Для использования в качестве основного механизма RM
будет слишком много головняка -- проверь сам, если хочешь.

IMHO так может иметь смысл выносить базовые метапакеты навроде
basesystem/interactivesystem/kde-mini, когда содержимое утряслось
в профиле и особенно не лопатится.  Смыслу так делать будет всё
так же много, если не получится сводить основные профили в один 
репозиторий или реализовать библиотеку субпрофилей.

> б) дефолты -- больная тема. Изредка настройки ПО выносятся в
> отдельные подпакеты (KDE) или бывает возможно уговорить
> майнтейнеров подумать об этом (XFCE), но чаще конфигурационные
> файлы просто включаются в состав соответствующего пакета.

Да, конечно.  И ещё firefox сюда же.  Вон спроси mex3 at .

> Нужен либо административный ресурс для решения такого рода
> проблем, либо тупо класть конфиги в /etc/skel (см.
> xfce-defaults-lite).

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

> Так что нужно решить, действовать ли правильно (и с неизбежными
> жертвами в виде обиженных майнтейнеров, которых и без того
> мучают всякие репокопы ;) )

Не надо никого мучать -- лучше стараться сэкономить своё и чужое
время на ерунде так, чтоб осталось время вместе и с удовольствием
порешать такие вот вопросы ;-)

> или легализовать использование /etc/skel.

Плохо при поддержке.

> Да, опять-таки, результат с точки зрения дистрибутивостоителя
> должен выглядеть так:
> ./configure --with-defaults=xfce-minimal,mplayer-minimal,...

Ты представил себе размер и важность строчки configure при таком
подходе для небольшого дистрибутива?  Я уже давно, и расхотелось.

Гибкость _бывает_ излишней.

> г) вид носителя. Было бы глупо, кстати, не задействовать
> описанные выше механизмы для формирования VE.

Угу.  И не только VE, ещё и для qemu/vmware бы здорово.

> >  > -- и собирать официальный профиль с нужными --configure,
> > > а лучше с конфигурационным файлом (возвращаемся к spt?).
> После написанного выше уже очевидно, что для ./configure нужен
> какой-то враппер, читающий конфиг, и глупо каждому делать его в
> ~/bin/

Почему?  Собиральный скрипт boyarsh@ для Desktop довольно
специфичен для того хоста, на котором идёт сборка, и задач
Антона.

Подвернувшаяся в своём history под руку ещё печальней:

mkdir -p $TMP/mkimage-profiles-desktop && cd
$TMP/mkimage-profiles-desktop && autoconf && make distclean; cd;
rsync -qa --delete-after ~/mkimage/mkimage-profiles-desktop/
$TMP/mkimage-profiles-desktop/ && cd
$TMP/mkimage-profiles-desktop/ && (autoconf; ./configure
--with-aptconf=/home/mike/apt/apt.conf.M41 --with-distro=desktop
--with-version=4.1 --with-license=desktop --with-language=uk_UA
--with-kernel=std-def --with-outdir=/home/mike/out; nice time
make minimal.cd ) 2>&1 | tee ~/mkimage/build-`date
+%Y%m%d-%H%M`.log; ls -lh /home/mike/out/

Здесь есть что улучшать, но не спеши с обёрткой и конфигом:
я в ту сторону тоже уже успел подумать, пока не нравится.

Если хочешь, давай лучше вместе подумаем над этим:
http://fly.osdn.org.ua/~mike/ALT/docs/whitelabel/whitelabel.PNG
http://fly.osdn.org.ua/~mike/ALT/docs/whitelabel/whitelabel.flow
(apt-get install flow2dot graphviz)

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