mkimage-profiles/conf.d
Michael Shigorin 7258e7508a live.mk: added efi/isohybrid to webkiosk images
This has apparently been a TODO item stuck until finding out
whether efi and isohybrid conflict or not; it's been a *long*
time since this has been found out (no conflict) actually,
let's add isohybrid to all of the images as it's completely
free size-wise and efi to chromium image as it's the largest
base one (I don't think that adding any extra functionality
to the already overweight and full of potential and kinetic
security bugs "flash" flavour is a good idea as it would
promote its use among those who need EFI but not Flash).
2015-09-08 11:50:27 +03:00
..
armh.mk exterminate fonts-ttf-dejavu all over the place 2014-08-19 20:42:45 +04:00
desktop.mk desktop.mk: refactor net-eth usage with +net-eth 2014-08-26 22:38:45 +04:00
homeros.mk speech-*: refactored and unified 2013-11-22 21:28:37 +04:00
live.mk live.mk: added efi/isohybrid to webkiosk images 2015-09-08 11:50:27 +03:00
p7.mk regular.mk, p7.mk: server-samba4 flavour 2015-06-29 20:37:02 +03:00
README conf.d: further note on SYSTEM_PACKAGES 2015-06-29 16:35:05 +03:00
regular.mk regular.mk: added templates to gnome3 2015-09-06 17:52:49 +03:00
server.mk server.mk: amend net-eth usage either 2014-08-26 23:12:02 +04:00
simply.mk simply: fix installer boot (go sysvinit) 2012-12-17 14:40:45 +04:00
t7.mk t7.mk: added altlinux-t7-gnustep-systemd.iso 2014-03-31 23:44:23 +04:00
test.mk syslinux: dropped netinstall snippet (useless) 2015-06-22 23:16:50 +03:00
ve.mk ve.mk: initial ve/systemd-bare 2015-02-25 18:53:47 +03:00
vm.mk vm.mk: don't be shy with thin disk image size 2015-02-20 19:06:46 +03: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.

== conf.d ==

Этот каталог содержит включаемые фрагменты конфигурации образов с тем,
чтобы было удобнее параллельно разрабатывать специфические образы
без излишних merge conflict'ов.

Следует понимать, что основная цель появления mkimage-profiles на свет
-- это уменьшение "форков" внутри семейства дистрибутивных профилей.
Поэтому при возможности следует всё-таки работать над общей базовой
частью, включая скриптовые хуки и списки пакетов, а также оптимизировать
граф зависимостей между конфигурациями образов.

Попросту говоря, copy-paste -- тревожный признак.

Вместо него нередко может помочь выделение кусочков конфигурации
в пределах включаемого файла в цели mixin/*, которые не являются
самостоятельными или даже промежуточными, но включают полезные
группы настроек, нужных в различных образах, не наследующих
друг другу -- посмотрите существующие примеры использования.

По переменным (см. тж. doc/pkglists.txt):

* для пользовательского окружения (live, main) предназначены
  THE_PACKAGES, THE_LISTS, THE_GROUPS, THE_PACKAGES_REGEXP

* для "обычного общего" (live, main, rescue) есть COMMON_PACKAGES
  (NB: тоже попадают в базовую установку)

* SYSTEM_PACKAGES стоит применять крайне осторожно -- эти пакеты попадут
  во все стадии, в том числе в образ чувствительной к объёму install2
  (в stage1 -- только в инструментальный чрут); применяйте для того,
  что обязано быть и в инсталяторе, и в готовой системе (но не в rescue)

* для направленного действия служат:
** STAGE1_PACKAGES, STAGE1_PACKAGES_REGEXP (первая стадия загрузки)
** STAGE2_PACKAGES (инсталятор и спасательная/"живая" система)
** INSTALL2_PACKAGES (инсталятор)
** BASE_PACKAGES, BASE_LISTS, BASE_PACKAGES_REGEXP (базовая система)
** MAIN_PACKAGES, MAIN_LISTS, MAIN_PACKAGES_REGEXP (дополнительные пакеты)
** LIVE_PACKAGES, LIVE_LISTS, LIVE_PACKAGES_REGEXP ("живая" система)

* аналогично по модулям ядра:
** THE_KMODULES попадут в "пользовательскую" среду (live, main)
** STAGE1_KMODULES доступны в производных от stage2 (install2, live, rescue)
** BASE_KMODULES попадут в установку по умолчанию
** MAIN_KMODULES будут доступны для установки с носителя
** LIVE_KMODULES предназначены для LiveCD/LiveFlash

Не стоит бояться такого разнообразия, для большинства задач достаточно THE_*.

По подстановкам:

* $(VAR) подставляются перед их записью в $(CONFIG), который distcfg.mk
* $$(VAR) раскрываются позже, при включении $(CONFIG) и востребовании
  значений; в этом случае их значения могут изменяться до окончания
  конфигурации, а также зависеть от значений других переменных

По спискам пакетов:

* на этапе экспериментирования можно забивать прямо в описание образа
* при фиксации состояния стоит воспользоваться существующими списками,
  а дополнительные оформить как можно более чётко обособленными по тем
  задачам, для решения которых они и подобраны
* повторяющиеся логически связанные группы списков может иметь смысл
  выделить в фичу (см., например, power или x11)
* если явной фичи не наблюдается, но у группы дистрибутивов намечается
  заметная общая часть -- её можно выделить в промежуточную цель вида
  distro/.name, не являющуюся самостоятельно собираемой