b474bff468
Just in case the build.log will be inobvious, and it's easy to diagnose automatically. Thanks Andrey Stroganov for this use case. Thanks for improving the initial implementation go to raorn@ for kind commit lynch and to Yuri Bushmelev for actually suggesting something more concise. BTW the "1024" magic number was taken out of thin air: the "no free space" errors are most likely to happen while forming/populating a chroot (apt/rpm errors out) and chroots are roughly two orders of magnitude heftier than a megabyte. |
||
---|---|---|
bin | ||
doc | ||
features.in | ||
image.in | ||
pkg.in | ||
sub.in | ||
.gitignore | ||
clean.mk | ||
COPYING | ||
distro.mk | ||
functions.mk | ||
iso.mk | ||
libdistro.mk | ||
log.mk | ||
Makefile | ||
profile.mk | ||
README |
see also http://www.altlinux.org/Mkimage/Profiles/next quickstart: make server-base.iso (NB: requires configured http://en.altlinux.org/Hasher) configurables: ~/.mkimage/profiles.mk, see doc/profiles.mk.sample and libdistro.mk license: GPLv2+, see COPYING Концепция: - метапрофиль служит репозиторием для построения индивидуального профиля, по которому создаётся итоговый дистрибутив - для одноразовых модификаций можно подправить сгенерированный профиль, для долгосрочной разработки стоит вливать правки в метапрофиль (что требует больше навыков и времени) Особенности: - метапрофиль может быть полностью read-only при сборке - для сборки подыскивается предпочтительно tmpfs - в профиль копируются только нужные объекты; он автономен относительно метапрофиля Стадии работы: - инициализация дистрибутивного профиля - сборка конфигурации дистрибутива - наполнение дистрибутивного профиля - сборка дистрибутива Объекты: - дистрибутивы: + описываются в distro.mk + могут основываться один на другом + включают один или более субпрофилей по надобности + желательно избегать множественного наследования, см. тж. фичи - субпрофили: + список собирается в $(SUBPROFILES) + базовые комплекты помещены в подкаталогах под sub.in/; их наборы скриптов могут расширяться фичами - stage1: propagator, ядро инсталятора и initrd в т.ч. с firmware - stage2: базовый live-образ (и модули ядра, соответствующие stage1); используется только с модификаторами (см. соответствующие фичи): + stage2/install2: инсталятор + stage2/live: LiveCD + stage2/rescue: спасательная система - main: пакетная база к инсталяции (обязательная и дополнительная) - фичи: + список собирается в $(FEATURES) + законченные блоки функциональности (или наборы таковых) + описываются в индивидуальных features.in/*/config.mk + могут зависеть друг от друга и требовать субпрофили + при сборке $(BUILDDIR) содержимое указанных в $(FEATURES) фич (подкаталоги, соответствующие входящим в дистрибутив субпрофилям под их итоговыми названиями -- например, live, а не stage2/live) добавляется в профиль; затем выполняются generate.sh, generate.mk - списки пакетов (*_LISTS): просьба по возможности избегать дублирования NB: перечисленные в этих переменных файлы автоматически копируются в порождаемый профиль => не следует указывать пакаджлисты напрямую - индивидуальные пакеты (*_PACKAGES): следует крайне осторожно пользоваться SYSTEM_PACKAGES -- эти пакеты попадут во все стадии, в том числе в образ чувствительной к объёму install2 (в stage1 -- только в инструментальный чрут); применяйте для того, что обязано быть и в инсталяторе, и в готовой системе -- и не путайте с COMMON_PACKAGES (main, live, rescue) Результат: - при успешном завершении сборки образ называется сообразно дистрибутиву и укладывается в $(IMAGEDIR): + указанный явно, + либо ~/out/ (если возможно), + или $(BUILDDIR)/out/ иначе