ae7139f8b6
We've got some parts of it in build-distro feature, and some went to dev feature for no real reason. But a bare installer might go without package base, and LiveCDs other than live-builder might find local repository useful given aufs2 root overlay. Now the overall scheme is more straightforward: - a distro: + asks that a package repo be included + cares to further add the packages to it - a repo feature: + pulls in sub/main for it to happen + provides genbasedir script to create repo metadata + supplements live feature with repo configuration |
||
---|---|---|
.. | ||
desktop.mk | ||
live.mk | ||
README | ||
server.mk |
Этот каталог содержит включаемые фрагменты конфигурации образов с тем, чтобы было удобнее параллельно разрабатывать специфические дистрибутивы и VE без излишних merge conflict'ов. Следует понимать, что основная цель появления mkimage-profiles на свет -- это уменьшение "форков" внутри семейства дистрибутивных профилей. Поэтому при возможности следует всё-таки работать над общей базовой частью, включая скриптовые хуки и списки пакетов, а также оптимизировать граф зависимостей между конфигурациями образов. Попросту говоря, copy-paste -- тревожный признак. По переменным: * SYSTEM_PACKAGES стоит применять крайне осторожно -- эти пакеты попадут во все стадии, в том числе в образ чувствительной к объёму install2 (в stage1 -- только в инструментальный чрут); применяйте для того, что обязано быть и в инсталяторе, и в готовой системе; * для "обычного общего" (main, live, rescue) есть COMMON_PACKAGES. По подстановкам: * $(VAR) подставляются перед их записью в $(CONFIG), который distcfg.mk; * $$(VAR) раскрываются позже, при включении $(CONFIG) и востребовании значений -- таким образом их значения могут изменяться до окончания конфигурации, а также зависеть от значений других переменных;