mkimage-profiles/conf.d

== conf.d ==
Этот каталог содержит включаемые фрагменты конфигурации образов с тем,
чтобы было удобнее параллельно разрабатывать специфические дистрибутивы
и VE без излишних merge conflict'ов.

Следует понимать, что основная цель появления mkimage-profiles на свет
-- это уменьшение "форков" внутри семейства дистрибутивных профилей.
Поэтому при возможности следует всё-таки работать над общей базовой
частью, включая скриптовые хуки и списки пакетов, а также оптимизировать
граф зависимостей между конфигурациями образов.

Попросту говоря, copy-paste -- тревожный признак.

По переменным (см. тж. ../doc/pkglists.txt):

- для пользовательского окружения (live, main) предназначены
  THE_PACKAGES, THE_LISTS, THE_GROUPS, THE_PACKAGES_REGEXP

- для "обычного общего" (live, main, rescue) есть COMMON_PACKAGES
  (NB: тоже попадают в базовую установку)

- SYSTEM_PACKAGES стоит применять крайне осторожно -- эти пакеты попадут
  во все стадии, в том числе в образ чувствительной к объёму install2
  (в stage1 -- только в инструментальный чрут); применяйте для того,
  что обязано быть и в инсталяторе, и в готовой системе

- для направленного действия служат:
  * STAGE1_PACKAGES, STAGE1_PACKAGES_REGEXP (первая стадия загрузки)
  * STAGE2_PACKAGES (инсталятор и спасательная/"живая" система)
  * INSTALL2_PACKAGES (инсталятор)
  * BASE_PACKAGES, BASE_LISTS, BASE_PACKAGES_REGEXP (базовая система)
  * MAIN_PACKAGES, MAIN_LISTS, MAIN_PACKAGES_REGEXP (дополнительные пакеты)
  * LIVE_PACKAGES, LIVE_LISTS, LIVE_PACKAGES_REGEXP ("живая" система)

- аналогично по модулям ядра:
  * THE_KMODULES попадут в "пользовательскую" среду (live, main)
  * STAGE1_KMODULES доступны в производных от stage2 (install2, live, rescue)
  * BASE_KMODULES попадут в установку по умолчанию
  * MAIN_KMODULES будут доступны для установки с носителя
  * LIVE_KMODULES предназначены для LiveCD/LiveFlash

Не стоит бояться такого разнообразия, для большинства задач достаточно THE_*.

По подстановкам:
- $(VAR) подставляются перед их записью в $(CONFIG), который distcfg.mk
- $$(VAR) раскрываются позже, при включении $(CONFIG) и востребовании
  значений; в этом случае их значения могут изменяться до окончания
  конфигурации, а также зависеть от значений других переменных

По спискам пакетов:
- на этапе экспериментирования можно забивать прямо в описание образа
- при фиксации состояния стоит воспользоваться существующими списками,
  а дополнительные оформить как можно более чётко обособленными по тем
  задачам, для решения которых они и подобраны
- повторяющиеся логически связанные группы списков может иметь смысл
  выделить в фичу (см., например, power или x11)
- если явной фичи не наблюдается, но у группы дистрибутивов намечается
  заметная общая часть -- её можно выделить в промежуточную цель вида
  distro/.name, не являющуюся самостоятельно собираемой