[devel-distro] I: Lite for 4.1 и проблемы инфраструктуры
Michael Shigorin
mike at osdn.org.ua
Mon Nov 17 00:57:21 MSK 2008
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/
More information about the devel-distro
mailing list