716744888a
Maybe it's worth moving to the kernel feature as well. |
||
---|---|---|
.. | ||
desktop.mk | ||
homeros.mk | ||
live.mk | ||
README | ||
regular.mk | ||
server.mk | ||
simply.mk | ||
test.mk | ||
vm.mk |
== 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, не являющуюся самостоятельно собираемой