Go to file
Michael Shigorin 895fae7d82 BELL support
Implemented opportunistic alarm support as proposed by torabora;
the actual result depends on readline and/or terminal settings
(read up on "visual bell" vs "audible bell" in case it's wrong).

TODO: this ought to be shifted downstream when proper logging
framework is there.
2011-11-04 16:54:41 +02:00
bin features.in/Makefile: fixups 2011-11-04 16:54:41 +02:00
conf.d introduced conf.d/ for distro, ve config snippets 2011-11-04 16:54:41 +02:00
doc BELL support 2011-11-04 16:54:41 +02:00
features.in stage2-based debug fixup 2011-11-04 16:54:41 +02:00
image.in logging tweaks for better readability 2011-11-04 16:54:41 +02:00
lib BELL support 2011-11-04 16:54:41 +02:00
pkg.in avoid "nothing to commit" in build.log 2011-11-04 16:54:41 +02:00
sub.in stage2-based debug fixup 2011-11-04 16:54:41 +02:00
.gitignore kernel and BUILDDIR fixes 2011-11-04 16:15:29 +02:00
COPYING actually released as free software 2011-11-04 16:15:30 +02:00
Makefile introduced conf.d/ for distro, ve config snippets 2011-11-04 16:54:41 +02:00
QUICKSTART official {distro,ve}/* support 2011-11-04 16:54:41 +02:00
README official {distro,ve}/* support 2011-11-04 16:54:41 +02:00

This file contains ambiguous Unicode characters

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 mkimage-profiles!

English quickstart: make distro/server-base.iso;
see http://en.altlinux.org/Hasher (and a large tmpfs).

Configurables: ~/.mkimage/profiles.mk;
see doc/profiles.mk.sample and libdistro.mk

License: GPLv2+, see COPYING.

Most docs in Russian, welcome to learn it or ask for English.
См. тж. http://www.altlinux.org/Mkimage/Profiles/next

Концепция:
- метапрофиль служит репозиторием для построения индивидуального
  профиля, по которому создаётся итоговый дистрибутив
- для одноразовых модификаций можно подправить сгенерированный
  профиль, для долгосрочной разработки стоит вливать правки
  в метапрофиль (что требует больше навыков и времени)

Особенности:
- метапрофиль может быть полностью read-only при сборке
- для сборки подыскивается предпочтительно tmpfs
- в профиль копируются только нужные объекты;
  он автономен относительно метапрофиля

Стадии работы:
- инициализация дистрибутивного профиля
- сборка конфигурации дистрибутива
- наполнение дистрибутивного профиля
- сборка дистрибутива

Объекты:
- виртуальные окружения:
  + описываются в lib/ve.mk
  + могут основываться одно на другом
- дистрибутивы:
  + описываются в lib/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/ иначе