d5a5941f96
This is quite a large-scale change since mkimage-profiles got used to baking distributions over the last year, and virtual environments are quite different, so e.g. image.in/Makefile had to be split in two with the main part of it moved into features.in/iso/lib/. Short overview: - features.in/Makefile: lib/ support (supporting VE images requires dynamic modifications to image.in/Makefile before starting the build; the most natural way to achieve that seems to use features mechanism along with makefile include dir) - packaging format related part moved into features.in/pack (should be better prepared for diversity either) - features.in/iso renamed to features.in/build-distro - features.in/ve renamed to features.in/build-ve + NB: these could not be merged as e.g. features.in/build due to completely different script hooks - lib/image.mk renamed to lib/build.mk - image, config, log postprocessing moved downstream - added a sort of a topping in the form of lib/sugar.mk - assorted style fixups (like ifeq usage) - clean.mk: reliability fix (the problem was observed by Oleg Ivanov and me too but finally it did get the attention quantum) - reviewed, updated and extended docs + QUICKSTART: should be[come] a step-by-step guide (thanks Leo-sp50 for prodiving feedback) |
||
---|---|---|
.. | ||
main | ||
stage1 | ||
stage2 | ||
Makefile | ||
README |
Этот каталог содержит субпрофили; содержимое затребованных (названия которых содержатся в значении переменной SUBPROFILES, которую заполняют цели sub/* -- см. ../lib/distro.mk) будет скопировано в каталог $(BUILDDIR)/image/ формируемого профиля. Просьба ответственно относиться к изменению существующих субпрофилей и вдумчиво -- к созданию новых; возможно, достаточно всего лишь оформить нужное новой фичей (см. ../features.in/). Обратите внимание: поскольку сборка частей дистрибутивного образа и происходит в каталогах субпрофилей, то повторное использование одного простого субпрофиля в рамках сгенерированного профиля штатным образом невозможно. Если требуется создать несколько близких по реализации субпрофилей, изучите stage2 и задействующие его фичи. Краткое описание существующих вариантов: - stage1: propagator и загрузчик (совместно с фичей syslinux); типично требуется для инсталяторов, live- и rescue-образов, но может использоваться без добавления таковых в образ, обеспечивая сетевую загрузку второй стадии - stage2: наиболее сложный технологически субпрофиль, поскольку он является только базовым для получения ряда итоговых частей дистрибутива (install2, live, rescue); задействуется для этого только опосредованно через use/stage2/* и модифицирует stage1 в силу наличия связи между ними (в stage1 попадает образ ядра и firmware, в stage2 -- соответствующие модули) - main: пакетная база, укладываемая на образ (NB: поскольку рабочий чрут в этом случае не содержит ничего, кроме пакетов, добавлять image-scripts.d/* смысла нет, только scripts.d/*)