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

[Eugene Prokopiev]

16.11.08, Michael Shigorin написал(а):

>  > А хотелось бы вынести дефолты DM/DE, шрифтов (а может и группы
>  > ПО?) в локальные настройки
>
>
> Ну так вынеси и обеспечь наличие варианта, не изменяющего ничего
>  относительно текущего состояния.

Дык перепиливать все надо ...

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

1) basesystem без Х (но с поднятым по дефолту sshd)
2) Xorg c драйверами (+ fake WM в виде xterm, что ли) и шрифтами
3) разные простые WM (wm-icewm, wm-openbox и т.д.) с окружением (для
openbox, например, это будет obconf и неопакеченный еще у нас obmenu)
4) полноценные DE c _минимальным_ окружением и с _полным_ окружением
5) DM
...
А вот дальше хуже, т.к. пошло прикладное ПО, и тут у разных
дистростоителей могут быть сильно разные предпочтения вплоть до того,
что тебе нужен украинский, а мне -- нет. Но группы нужны, пусть даже
они будут называться enp-favorite-apps.

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

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

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

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

Далее. Группы -- это не все, нужны также:

а) хаки -- для них есть удачное решение в виде installer-feature-*, но
плохо их жесткое прошивание в инсталлере. В итоге я не могу
по-человечьи собрать десктопный дистрибутив с включенным по дефолту
ssh. Было бы неплохо иметь предопределенные features в инсталлере,
которые можно включать/выключать так:

./configure --with-installer-features=-one,+two

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

б) дефолты -- больная тема. Изредка настройки ПО выносятся в отдельные
подпакеты (KDE) или бывает возможно уговорить майнтейнеров подумать об
этом (XFCE), но чаще конфигурационные файлы просто включаются в состав
соответствующего пакета. Нужен либо административный ресурс для
решения такого рода проблем, либо тупо класть конфиги в /etc/skel (см.
xfce-defaults-lite). Так что нужно решить, действовать ли правильно (и
с неизбежными жертвами в виде обиженных майнтейнеров, которых и без
того мучают всякие репокопы ;) ) или легализовать использование
/etc/skel. Да, опять-таки, результат с точки зрения
дистрибутивостоителя должен выглядеть так:

./configure --with-defaults=xfce-minimal,mplayer-minimal,...

в) дизайн - ну это типа есть, только я не уверен в небходимости такого
количества пакетов, по которым размазан дизайн

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

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

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

-- 
С уважением,
Прокопьев Евгений