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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
I've been considering a way to avoid confusion between:
- a tde based livecd with systemd;
- a tde based livecd with sysvinit;
- a tde based installer with sysvinit
and finally came to conclusion that regular-sysv prefix
will be common for installers with sysvinit within regular.mk
and p7.mk; this might be not perfect but should be good enough.
Note that while regular-sysv-tde.iso is buildable and installs
just fine at the moment I don't plan to publish Sisyphus based
installer builds as a rule since these require extra knowledge
regarding daily use (starting with http://altlinux.org/changes
and/or https://lists.altlinux.org/mailman/listinfo/sisyphus ML
subscription).
Sisyphus-based rescue image is fine as well as LiveCDs are;
installable LiveCDs (most of regular-*.iso) are actually
risky in case user actually installs *and* updates those
having ignored the red "unstable" status in the branding,
and that's the line I'm not going to cross that often.
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 -- тревожный признак.
По переменным (см. тж. ../doc/pkglists.txt):
* для пользовательского окружения (live, main) предназначены
THE_PACKAGES, THE_LISTS, THE_GROUPS, THE_PACKAGES_REGEXP
* для "обычного общего" (live, main, rescue) есть COMMON_PACKAGES
(NB: тоже попадают в базовую установку)
* SYSTEM_PACKAGES стоит применять крайне осторожно -- эти пакеты попадут
во все стадии, в том числе в образ чувствительной к объёму install2
(в stage1 -- только в инструментальный чрут); применяйте для того,
что обязано быть и в инсталяторе, и в готовой системе
* для направленного действия служат:
** 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, не являющуюся самостоятельно собираемой
6d1f4f6b89