[Antique] Создание профиля Antique на базе m-p

[Michael Shigorin]

On Tue, Jul 12, 2011 at 11:54:18AM +0400, Ivanov Oleg wrote:
> Начал ваять минимал, вопрос - куда лучше поместить описание
> сборки X-сов ?

Описание соответствующего кусочка конфигурации дистрибутива
(и туда же скрипты к нужным стадиям) -- в features.in/xorg/

> По логике вроде проситься в /sub.in/xorg , но не уверен
> в правильности.

Это ж не отдельный целый субпрофиль :)

Опять же -- что надо написать яснее/проще в README,
чтоб было понятней, куда с чем предлагается двигаться?

> Что и как там прописывать , может есть уже какая-нибудь готовая
> конструкция ?  Или можно пока просто тупо взять шаблоны из
> m-p-d ?

Если хочешь, поэкспериментируй -- а вообще давай я попробую
изобразить начальное состояние такой фичи, чтоб удобней было.

PS: в аттаче копия моей текущей тудушки по m-p (as is);
IMHO главные неприятности пока -- отсутствие возможности
условного включения (например, по архитектуре) и поддержки
различных типов загрузчиков (grub/lilo/syslinux4) -- могут
потребоваться правки installer.git (и alterator-syslinux4).
В остальном скользкие места старался помечать FIXME/###/TODO.

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
----------- следующая часть -----------
check-packages! ==> две стадии: check all и check this?
+-> mki-image-pkgs? (CHROOT_IMAGE_PKGS) <- check this
`-> sub.in/check? <- check all [но: скопировать все pkg.in/lists ещё куда-то?]
    +-> NB: проверять списки по одному, т.к. conflicts:, если mki-*
    `-> apt-cache pkgnames vs ... search ''? [mki-prepare]
<legion> не проще ли написать утилиту которая дёрнет mki-expand-pkgs для листа ?
<legion> если expand проходит, то значит всё ок
<legion> мне кажется что можно сделать глобальный check-packages
<legion> списки в IMAGE_PACKAGES есть
<legion> достаточно просто сделать mki-expand-pkgs в check-packages
+-> хорошо, а как насчёт prepare-workdir?  дважды не хочется
`-> check: check-subdirs check-packages (касательно вложенных стадий)

$arch-only/skip!

grub OR lilo!

feature/freedos
`-> prealpha done, blob img [ms-sys, dosemu-freedos], [vesa troubles suse gfxboot]

README: пакеты рекомендуется набивать LIST'ами;
        BASE_PACKAGES нет потому, что инсталер поставит .base;
	MAIN_PACKAGES попадут в образ, но и только
groups: востребованность по умолчанию может зависеть от дистрибутива

policy: скрипты не правят друг друга и чужие конфиги;
        очень аккуратно описать случай со squashcfg.mk

*.mk: reinclusion check?

<hsv> В принципе, наверное можно installer-steps хуком в /usr/share/install2 положить...

*MODULE*: thoroughly document the difference between e.g. *.ko,
          kernel-modules-* and package/tag lists (current naming
	  is somewhat mangled) -- re var names

GLOBAL_BOOT_LANG; GLOBAL_HSH_NUMBER; GLOBAL_HSH_LANGS; GLOBAL_HSH_USE_QEMU(?); BOOT_PUBL(?)

syslinux4: see also PACKAGES_REQUIRED_COPY_ISOLINUX and friends

== later ==

plymouth: тж. m-p-d::profiles/scripts.d/80-make-initfs << после десктопа

rescue += ext3grep << после rescue/live

localboot: различается для iso и flash (boyarsh: если на flash тоже isolinux, как различить?) << после native flash

http://syslinux.zytor.com/wiki/index.php/Ifcpu64.c32 << после 32+64?

features.in/*/config.mk: приходится вручную добавляться в FEATURES

tags2lists: [ -e "s,^\(.*\)@\(.*\),\1 \2," ]? ("... ... @somedir") => not naive