mkimage-profiles/features.in/00example
Michael Shigorin d5a5941f96 official {distro,ve}/* support
This is quite a large-scale change since mkimage-profiles got used to
baking distributions over the last year, and virtual environments are
quite different, so e.g. image.in/Makefile had to be split in two with
the main part of it moved into features.in/iso/lib/.

Short overview:

- features.in/Makefile: lib/ support
  (supporting VE images requires dynamic modifications
  to image.in/Makefile before starting the build;
  the most natural way to achieve that seems to use
  features mechanism along with makefile include dir)

- packaging format related part moved into features.in/pack
  (should be better prepared for diversity either)
- features.in/iso renamed to features.in/build-distro
- features.in/ve  renamed to features.in/build-ve
  + NB: these could not be merged as e.g. features.in/build
    due to completely different script hooks

- lib/image.mk renamed to lib/build.mk
- image, config, log postprocessing moved downstream
- added a sort of a topping in the form of lib/sugar.mk
- assorted style fixups (like ifeq usage)

- clean.mk: reliability fix (the problem was observed by Oleg Ivanov
  and me too but finally it did get the attention quantum)

- reviewed, updated and extended docs
  + QUICKSTART: should be[come] a step-by-step guide
    (thanks Leo-sp50 for prodiving feedback)
2011-11-04 16:54:41 +02:00
..
main/scripts.d docs day 2011-11-04 16:15:29 +02:00
config.mk docs day 2011-11-04 16:15:29 +02:00
generate.mk server-ovz; KDEFAULT; syslinux features reworked 2011-11-04 16:15:29 +02:00
generate.sh docs day 2011-11-04 16:15:29 +02:00
README official {distro,ve}/* support 2011-11-04 16:54:41 +02:00
README.en docs day 2011-11-04 16:15:29 +02:00

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Этот каталог содержит "заготовку" фичи в качестве примера
и должен дать представление о том, какой код _может_ быть
включён в настоящую фичу: статические файлы, два makefile
для создания конфигурации и генерирования части профиля,
а также шелл-скрипт для генерирования.

Вовсе не требуется втягивать всё в свою фичу, лучше постараться
сделать её минимальной, самодостаточной и полезной в качестве
"кирпичика".

Единственной необходимой частью фичи является файл config.mk,
который включается в distro.mk верхнего уровня и предоставляет
цель вида use/*, специфичную для данной фичи (а также добавляет
её в переменную FEATURES -- к сожалению, реализовать добавление
автоматом не представляется возможным).  Если название фичи не
упоминается в списке, содержащемся в этой переменной, то она
не задействуется при построении профиля, а только при сборке
конфигурации дистрибутива.

Остальное содержимое является дополнительным и используется
в таком порядке (см. features.in/Makefile):

- сперва в $(BUILDDIR)/image/ копируются все подкаталоги,
  соответствующие именам субпрофилей, запрошенных для
  дистрибутивного профиля; при этом они сливаются с деревом,
  которое уже сформировано субпрофилями (../sub.in/*) и уже
  скопированными фичами; если какие-либо файлы перекрылись
  по именам, rsync должен оставить резервные копии (*~),
  которые должны просигнализировать о беспорядке;

- затем запускается generate.sh, если существует и исполнимый;

- затем используется generate.mk, если существует и непустой.

Например, если используются субпрофили stage1, stage2/install2
и main, вы можете решить собрать специфические для фичи скрипты
инсталятора в install2/image-scripts.d/ (или необходимые для
операций с пакетной базой -- в main/scripts.d/, смотря чего
надо добиться; загляните также в документацию mkimage).

А если требуются нетривиальные действия по конфигурированию
(как при сборке syslinux.cfg из кусочков, в зависимости от того,
что из запрошенных модулей оказалось в наличии) -- то их можно
произвести из generate.sh и generate.mk.

Пожалуйста, присылайте отзывы о (бес)полезности кода в этом каталоге
mike@altlinux.org.