IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
These have appeared in desktop.mk, regular.mk, vm.mk
over time, and there are two problems around.
The minor one is that mixins have been introduced as
handy reusable bits close in context of their use;
this practically means that they fall under the same
class restrictions as their parent targets, that is
a mixin coming from regular.mk will only be available
for "distro" IMAGE_CLASS, and so on.
The major one is probably the worst design flaw in m-p:
building images from ground up, where ground is a valid
standalone buildable target as well.
Life has shown that we rather want to build up images
the other way around, choosing what essentials go in first
and then fitting the fine details along with the packaging.
The first sign of this difference appeared with ARMv7 Simply:
we had a well-built configuration aiming for x86 ISO, still
we needed roughly the same app/environment configuration
put into armh disk image.
Those platforms were different enough that we didn't actually
plan shipping *lots* of distributions but the problem was clear,
and it was much alike to the one that sprang m-p to life in the
first place (when we had a range of "common" distros and needed
to create and maintain a set of "school" ones that mostly had
similar or even identical difference to their respective base
ones -- and we couldn't do something like conf.d/p8.mk does now).
So mixins are going to become the softer way to turn m-p's
target configuration chain upside down to considerable extent:
build up what you're going to mix into the various deliverables,
and make it as portable across image classes, hardware platforms,
repository branches as feasible so that total maintenance effort
needed goes down or at least doesn't spike too bad.
And here's the first strike at that.
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
== 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>
24defe9461