85223fc12a
This change mostly concerns with making icewm flavour the lean one again. The goal is to widen the dynamic range of regular image features: icewm is not a desktop thus can bear withouth systemd-logind even if a bunch of network-managing-media-mounting crap has been rigged to depend on it, and ALT domain client should be included in most builds for convenient testing in SMB environments but can stay out of this minimal and "different" image. It also receives the "un-def" kernel flavour (3.8.0 as of today) which might benefit from the more available testing facility too. Its branding is also simplified, plain syslinux menu is fine; in similar vein, refind feature is flipped from icewm-only to all-but-icewm set of images with its state being good enough as of refind 0.6.7 and mkimage 0.2.7. |
||
---|---|---|
.. | ||
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, не являющуюся самостоятельно собираемой