features.txt

== Фичи ==

Особенности дистрибутива, не учитываемые в пакетной базе
или зависящие от переменных времени сборки/установки образа;
по необходимости влияют на конфигурацию, приносят с собой
или запрашивают скрипты, которые могут быть оформлены как:

* scripts.d/ или image-scripts.d/ различных стадий;
* в виде патчей в image-patches.d/ различных стадий;
* пакеты installer-feature-*
  (тж. https://www.altlinux.org/Installer/beans).

В большинстве случаев можно рекомендовать создание feature
средствами метапрофиля, поскольку при этом дерево кода более
удобно для анализа и обновления (и в отличие от _m-p-d_ -- нет
вынужденной необходимости либо контролировать включение нужных
фич "вручную" в скриптах по косвенным признакам, либо выносить
их в пакеты installer-feature-*); также возможно добиться большей
степени интеграции по данным (например, язык gfxboot и LiveCD).

Создание и упаковку installer-feature-* можно рекомендовать, если:

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

Стоит избегать изменения пакетных умолчаний в случае, когда их
представляется осмысленным и возможным скорректировать в пакете:
таким образом они станут более дистрибутивными.

Обратите внимание, что фичи включаются в комплект инкрементально:
что добавили, то уже не убрать; поэтому при необходимости следует
выделять промежуточные цели сборки, собирающие необходимые фичи
и оставляющие те, по которым есть расхождения, на включение ближе
к конечной дистрибутивной цели.

Соглашение по именованию таково, что цели use/ФИЧА и use/ФИЧА/...
определяются в файле features.in/ФИЧА/config.mk и только в нём.