forked from altcloud/mkimage-profiles
ec3d40cc1b
The __frontend variable was introduced to address the needs of alterator-mkimage module: list the images available in one column, purge the builddir. Looks like we should consider other cases with redirected stdout (cron builds, piped calls, etc) like fundamentally non-interactive and behave the same. So commit 3a8af6b55d888d25c1d97561ed2ecf37ff28ad71's description is wrong now; the current cleanup rules are: - if CLEAN=0 or DEBUG>1, don't do it; - if CHECK or REPORT is set, don't do it; - otherwise if at least one of the following conditions is true: + there's more than one target being built in a row; + stdout was redirected (cronjob, alterator-mkimage...); + metaprofile directory is read-only ...then do a distclean. If that doesn't suit your needs, describe the particular situation please. Thanks cas@ for wondering aloud whether greppable output is unsupported with `make help'. |
||
---|---|---|
.gear | ||
bin | ||
conf.d | ||
doc | ||
features.in | ||
image.in | ||
lib | ||
pkg.in | ||
sub.in | ||
.gitignore | ||
COPYING | ||
main.mk | ||
Makefile | ||
QUICKSTART | ||
README | ||
reports.mk |
== Welcome to m-p! ==
*Brief summary*
Configurables: ~/.mkimage/profiles.mk;
see doc/params.txt and conf.d/README
License: GPLv2+, see COPYING
Most docs are in Russian, welcome to learn it or ask for English.
Задача:
* конфигурирование и создание образов на базе ALT Linux
Концепция:
* конфигурация, как и образ -- объект постадийной сборки
* метапрофиль служит репозиторием для построения индивидуального
профиля, по которому создаётся итоговый образ
Особенности:
* метапрофиль при сборке может быть доступен только на чтение
* для сборки подыскивается предпочтительно tmpfs
* в профиль копируются только нужные объекты;
он автономен относительно метапрофиля
Стадии работы:
* инициализация сборочного профиля
* сборка конфигурации образа
* наполнение сборочного профиля
* сборка образа
Объекты:
* дистрибутивы и виртуальные среды/машины:
** описываются в conf.d/*.mk
** могут основываться на предшественниках, расширяя их
** дистрибутивы также включают один или более субпрофилей по надобности
** желательно избегать множественного наследования, см. тж. фичи
* субпрофили:
** список собирается в $(SUBPROFILES)
** базовые комплекты помещены в подкаталогах под sub.in/;
их наборы скриптов могут расширяться фичами
* фичи:
** законченные блоки функциональности (или наборы таковых)
** описываются в индивидуальных features.in/*/config.mk
** могут требовать другие фичи, а также субпрофили
** накопительный список собирается в $(FEATURES)
** при сборке $(BUILDDIR) содержимое фич добавляется в профиль
* списки пакетов (*_LISTS):
** просьба по возможности избегать дублирования (см. bin/pkgdups)
* индивидуальные пакеты (*_PACKAGES): см. тж. conf.d/README
Результат:
* при успешном завершении сборки образ называется по имени цели
и укладывается в $(IMAGEDIR):
** указанный явно,
** либо ~/out/ (если возможно),
** или $(BUILDDIR)/out/ иначе
* формируются отчёты, если запрошены (REPORT)
См. тж.:
* http://altlinux.org/m-p: обзорная документация, в т.ч. howto
* doc/:
** params.txt: переменные, указываемые при запуске сборки
** pkglists.txt: формирование состава образа
** features.txt: обзор подключаемых особенностей
Примечание: пути в документации задаются от каталога верхнего уровня,
если не указаны как относительные в явном виде (./) или по смыслу.
Удачи; что не так -- пишите.
Michael Shigorin <mike@altlinux.org>