Go to file
Michael Shigorin 0b0ad61b34 install2: split 85cleanup-legacy off 85cleanup-cjk
We have several categories of overhead data:
- legacy 8-bit fonts, locales and gconv modules;
- illegible fonts (e.g. 5x7 or 6x10);
- obsolete vendor specific stuff;
- CJK (which would require proper support anyways).

Notes:
- JIS and things like VISCII are 8-bit either
  and thus might be reconsidered as "legacy";
- proper CJK support would probably include
  scalable fonts and an input method helper;
- main target audience is rather ru/uk/be by now.

(dropped wireless from install2 either)
2011-11-04 16:15:29 +02:00
bin assorted fixups 2011-11-04 16:15:29 +02:00
doc README updates 2011-11-04 16:15:29 +02:00
features.in moved stage1 scripts into feature.in/installer 2011-11-04 16:15:29 +02:00
image.in 01-genbasedir: dropped dup cleanup 2011-11-04 16:15:29 +02:00
pkg.in README updates 2011-11-04 16:15:29 +02:00
sub.in install2: split 85cleanup-legacy off 85cleanup-cjk 2011-11-04 16:15:29 +02:00
.gitignore kernel and BUILDDIR fixes 2011-11-04 16:15:29 +02:00
clean.mk server-ovz; KDEFAULT; syslinux features reworked 2011-11-04 16:15:29 +02:00
distro.mk moved stage1 scripts into feature.in/installer 2011-11-04 16:15:29 +02:00
functions.mk initial logging subsystem 2011-11-04 16:15:29 +02:00
iso.mk installer firmware support 2011-11-04 16:15:29 +02:00
libdistro.mk pass squashfs options from stage1 test to install2 2011-11-04 16:15:29 +02:00
log.mk README updates 2011-11-04 16:15:29 +02:00
Makefile kernel and BUILDDIR fixes 2011-11-04 16:15:29 +02:00
profile.mk README updates 2011-11-04 16:15:29 +02:00
README README updates 2011-11-04 16:15:29 +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.

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

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

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

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

Объекты:
- дистрибутивы: distro.mk, могут основываться один на другом;
  желательно избегать множественного наследования, используя
  вместо него блоки use/*
- субпрофили (список собирается в $(SUBPROFILES)):
  + stage1: propagator и ядро инсталятора
  + install2: сам инсталятор
  + main: пакетная база к инсталяции (обязательная и дополнительная)
  + ...
- блоки функциональности use/*: не являются самостоятельными
  (не путать с дистрибутивами), но законченными; описываются
  в use.mk либо же в индивидуальных features.in/*/config.mk,
  если необходимо дополнить не только distcfg.mk, а и дерево
  формируемого профиля
- фичи: законченные кусочки функциональности, могут зависеть
  друг от друга; сливаются с соответствующими субпрофилями
  при сборке $(BUILDDIR), могут нести с собой копируемые в один
  или несколько субпрофилей каталоги/файлы и могут выполнять
  необходимые действия во время сборки после копирования
  (generate.sh, generate.mk).  NB: добавляем в $(FEATURES)
  (из того же config.mk, который будет включён в distro.mk)!
- списки пакетов: большая человеческая просьба по возможности
  избегать дублирования и подумать над pkg/lists/tagged...

NB: следует крайне осторожно пользоваться COMMON_PACKAGES,
    т.к. указанные пакеты попадут во все стадии (в т.ч.
    stage1 и install2, чувствительные к объёму).

Результат:
- при успешном завершении сборки образ называется сообразно
  дистрибутиву и укладывается в $(IMAGEDIR):
  + указанный явно,
  + либо ~/out/ (если возможно),
  + или $(BUILDDIR)/out/ иначе