Commit b69a8a63 authored by Michael Shigorin's avatar Michael Shigorin

README update

reword 'em, structurize 'em, facelift 'em too
parent 24ce6f54
......@@ -5,7 +5,7 @@
# 3. copy subprofiles, script hooks, and package lists/groups
# from metaprofile to new profile (as needed)
# --- in BUILDDIR
# 4. build subprofiles and subsequently image
# 4. build subprofiles and subsequently the image
all help:
@echo '** available distribution targets:'
......
......@@ -7,9 +7,8 @@ configurables: ~/.mkimage/profiles.mk,
see doc/profiles.mk.sample and libdistro.mk
Концепция:
- метапрофиль служит репозиторием всего возможно нужного для
построения индивидуального профиля, по которому создаётся
итоговый дистрибутив
- метапрофиль служит репозиторием для построения индивидуального
профиля, по которому создаётся итоговый дистрибутив
- для одноразовых модификаций можно подправить сгенерированный
профиль, для долгосрочной разработки стоит вливать правки
в метапрофиль (что требует больше навыков и времени)
......@@ -27,32 +26,32 @@ see doc/profiles.mk.sample and libdistro.mk
- сборка дистрибутива
Объекты:
- дистрибутивы: distro.mk, могут основываться один на другом;
желательно избегать множественного наследования, используя
вместо него блоки use/*
- субпрофили (список собирается в $(SUBPROFILES)):
+ stage1: propagator и ядро инсталятора
+ install2: сам инсталятор
+ main: пакетная база к инсталяции (обязательная и дополнительная)
+ ...
- блоки функциональности use/*: не являются самостоятельными
(не путать с дистрибутивами), но законченными; описываются
в use.mk либо же в индивидуальных features.in/*/config.mk,
если необходимо дополнить не только distcfg.mk, а и дерево
формируемого профиля
- фичи: законченные кусочки функциональности, могут зависеть
друг от друга; сливаются с соответствующими субпрофилями
при сборке $(BUILDDIR), могут нести с собой копируемые в один
или несколько субпрофилей каталоги/файлы и могут выполнять
необходимые действия во время сборки после копирования
(generate.sh, generate.mk). NB: добавляем в $(FEATURES)
(из того же config.mk, который будет включён в distro.mk)!
- списки пакетов: большая человеческая просьба по возможности
избегать дублирования и подумать над pkg/lists/tagged...
NB: следует крайне осторожно пользоваться COMMON_PACKAGES,
т.к. указанные пакеты попадут во все стадии (в т.ч.
stage1 и install2, чувствительные к объёму).
- дистрибутивы:
+ описываются в distro.mk
+ могут основываться один на другом
+ включают один или более субпрофилей по надобности
+ желательно избегать множественного наследования, см. тж. фичи
- субпрофили:
+ список собирается в $(SUBPROFILES)
+ базовые комплекты помещены в подкаталогах под sub.in/;
их наборы скриптов могут расширяться фичами
- stage1: propagator, ядро инсталятора и initrd в т.ч. с firmware
- install2: сам инсталятор (и модули ядра)
- main: пакетная база к инсталяции (обязательная и дополнительная)
- фичи:
+ список собирается в $(FEATURES)
+ законченные блоки функциональности (или наборы таковых)
+ описываются в индивидуальных features.in/*/config.mk
+ могут зависеть друг от друга и требовать субпрофили
+ при сборке $(BUILDDIR) содержимое указанных в $(FEATURES) фич
(подкаталоги, соответствующие входящим в дистрибутив субпрофилям)
добавляется в профиль; затем выполняются generate.sh, generate.mk
- списки пакетов (*_LISTS): просьба по возможности избегать дублирования
- индивидуальные пакеты (*_PACKAGES): следует крайне осторожно пользоваться
COMMON_PACKAGES -- эти пакеты попадут во все стадии, в том числе в образ
чувствительной к объёму install2 (в stage1 -- только в инструментальный
чрут); применяйте для того, что обязано быть и в инсталяторе, и в готовой
системе
Результат:
- при успешном завершении сборки образ называется сообразно
......
......@@ -2,20 +2,19 @@
каталоги, содержимое каждого из которых реализует одну из
подключаемых автономных возможностей дистрибутива.
Каждая фича должна содержать файл config.mk, включаемый
в ../distro.mk и как минимум содержащий добавление имени
этой фичи в переменную FEATURES на этапе создания конфигурации
профиля.
Каждая фича должна содержать задействуемый при построении
конфигурации будущего образа файл config.mk, включаемый
в ../distro.mk; он может описывать одну или более целей
вида use/*, дополняющих конфигурацию дистрибутива, и при
наличии дополнительных хуков для копирования или generate.*
должен добавить имя фичи в $(FEATURES).
На этапе создания собственно профиля этот каталог задействуется
На этапе генерации дистрибутивного профиля фичи рассматриваются
после инициализации профиля (см. ../image.in/) и копирования
субпрофилей (см. ../sub.in/); обход его подкаталогов производится
в порядке отсортированных по алфавиту имён из списка,
содержащегося в переменной FEATURES.
Для каждой фичи производится копирование подкаталогов,
соответствующих запрошенным субпрофилям, а также выполняется
скрипт generate.sh и задействуется generate.mk (при их наличии).
субпрофилей (см. ../sub.in/). Для каждой фичи, указанной
в $(FEATURES), копируются подкаталоги сообразно субпрофилям,
а также выполняется скрипт generate.sh и задействуется generate.mk
(при их наличии).
Несложный пример содержится в 00example/, более близкий к жизни
и нынешним пределам возможностей метапрофиля -- в syslinux/.
......@@ -3,7 +3,7 @@
При добавлении скриптов в image-scripts.d/ следует позаботиться,
чтобы в компактном livecd, которым является инсталятор, оказались
нужные утилиты (INSTALL2_PACKAGES). Перегружать его не следует,
нужные им утилиты (INSTALL2_PACKAGES). Перегружать его не следует,
поскольку это прямо влияет на требования по минимальному размеру
оперативной памяти для установки.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment