keremet/mkimage-profiles
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
5c3d58b8e4
mkimage-profiles/conf.d/README

51 lines
4.2 KiB
Plaintext
Raw Normal View History

introduced conf.d/ for distro, ve config snippets This was asked for by Leo-sp50 and torabora, and seems quite reasonable: let's provide means to keep at least some distribution configurations a bit apart, so that these can be considered more standalone in terms of hard warranted functionality but at the same time enjoying the common infrastructure. Considering lib/distro.mk: it's now experimentally pulled apart so that parallel development of different distro families can go on without major merge hassles. *Please* don't abuse with massive copy-paste. And before you ask: this might get extended to allow for "private" out-of-tree configurations being included since apparently there are goals with no meaning outside of some very particular context... but otherwise I'd like to encourage getting reusable bits in-tree.
2011-10-31 14:40:02 +04:00
Этот каталог содержит включаемые фрагменты конфигурации образов с тем,
чтобы было удобнее параллельно разрабатывать специфические дистрибутивы
full-view docs update - toplevel README received some long-needed refactoring + lowlevel detail moved, well, to lowlevel READMEs - reflected more thoroughly that m-p is not about distros anymore - dropped features.in/00example/README.en: it's already out-of-date a bit, and there's no perceived need in thorough English docs so far - wiki article got split into parts and somewhat rewritten, links updated - mv doc/{CodingStyle,style.txt}
2011-11-06 23:57:28 +04:00
и VE без излишних merge conflict'ов.
introduced conf.d/ for distro, ve config snippets This was asked for by Leo-sp50 and torabora, and seems quite reasonable: let's provide means to keep at least some distribution configurations a bit apart, so that these can be considered more standalone in terms of hard warranted functionality but at the same time enjoying the common infrastructure. Considering lib/distro.mk: it's now experimentally pulled apart so that parallel development of different distro families can go on without major merge hassles. *Please* don't abuse with massive copy-paste. And before you ask: this might get extended to allow for "private" out-of-tree configurations being included since apparently there are goals with no meaning outside of some very particular context... but otherwise I'd like to encourage getting reusable bits in-tree.
2011-10-31 14:40:02 +04:00
Следует понимать, что основная цель появления mkimage-profiles на свет
-- это уменьшение "форков" внутри семейства дистрибутивных профилей.
Поэтому при возможности следует всё-таки работать над общей базовой
частью, включая скриптовые хуки и списки пакетов, а также оптимизировать
full-view docs update - toplevel README received some long-needed refactoring + lowlevel detail moved, well, to lowlevel READMEs - reflected more thoroughly that m-p is not about distros anymore - dropped features.in/00example/README.en: it's already out-of-date a bit, and there's no perceived need in thorough English docs so far - wiki article got split into parts and somewhat rewritten, links updated - mv doc/{CodingStyle,style.txt}
2011-11-06 23:57:28 +04:00
граф зависимостей между конфигурациями образов.
introduced conf.d/ for distro, ve config snippets This was asked for by Leo-sp50 and torabora, and seems quite reasonable: let's provide means to keep at least some distribution configurations a bit apart, so that these can be considered more standalone in terms of hard warranted functionality but at the same time enjoying the common infrastructure. Considering lib/distro.mk: it's now experimentally pulled apart so that parallel development of different distro families can go on without major merge hassles. *Please* don't abuse with massive copy-paste. And before you ask: this might get extended to allow for "private" out-of-tree configurations being included since apparently there are goals with no meaning outside of some very particular context... but otherwise I'd like to encourage getting reusable bits in-tree.
2011-10-31 14:40:02 +04:00
Попросту говоря, copy-paste -- тревожный признак.
full-view docs update - toplevel README received some long-needed refactoring + lowlevel detail moved, well, to lowlevel READMEs - reflected more thoroughly that m-p is not about distros anymore - dropped features.in/00example/README.en: it's already out-of-date a bit, and there's no perceived need in thorough English docs so far - wiki article got split into parts and somewhat rewritten, links updated - mv doc/{CodingStyle,style.txt}
2011-11-06 23:57:28 +04:00
По переменным:
introduced THE_{KMODULES,PACKAGES,LISTS,GROUPS} As too many things started duplicating between distros proper and (e.g. corresponding) LiveCDs, it became apparent that a class of entities which end up working for THE_USER (not a sysadmin, and not a developer, just a Linux user) is in need. So THE_KMODULES will power installed basesystem and live image, while THE_PACKAGES, THE_LISTS and THE_GROUPS will participate in building those.
2011-12-19 23:28:42 +04:00
- SYSTEM_PACKAGES стоит применять крайне осторожно -- эти пакеты попадут
full-view docs update - toplevel README received some long-needed refactoring + lowlevel detail moved, well, to lowlevel READMEs - reflected more thoroughly that m-p is not about distros anymore - dropped features.in/00example/README.en: it's already out-of-date a bit, and there's no perceived need in thorough English docs so far - wiki article got split into parts and somewhat rewritten, links updated - mv doc/{CodingStyle,style.txt}
2011-11-06 23:57:28 +04:00
во все стадии, в том числе в образ чувствительной к объёму install2
(в stage1 -- только в инструментальный чрут); применяйте для того,
introduced THE_{KMODULES,PACKAGES,LISTS,GROUPS} As too many things started duplicating between distros proper and (e.g. corresponding) LiveCDs, it became apparent that a class of entities which end up working for THE_USER (not a sysadmin, and not a developer, just a Linux user) is in need. So THE_KMODULES will power installed basesystem and live image, while THE_PACKAGES, THE_LISTS and THE_GROUPS will participate in building those.
2011-12-19 23:28:42 +04:00
что обязано быть и в инсталяторе, и в готовой системе
- для "обычного общего" (live, main, rescue) есть COMMON_PACKAGES
(NB: попадают в базовую систему)
implemented {THE,BASE,LIVE}_PACKAGES_REGEXP There were STAGE1_PACKAGES_REGEXP and MAIN_PACKAGES_REGEXP but adding more of those was postponed to avoid bloat and bitrot; THE_PACKAGES_REGEXP is needed for use/firmware now and looks like BASE_PACKAGES_REGEXP and LIVE_PACKAGES_REGEXP will be useful before too long either. Docs updated to include stage-specific package related vatiables.
2012-04-10 19:14:01 +04:00
- для "пользовательского" окружения (live, main) предназначены
THE_PACKAGES, THE_LISTS, THE_GROUPS, THE_PACKAGES_REGEXP
- для строго направленного действия служат:
+ STAGE1_PACKAGES, STAGE1_PACKAGES_REGEXP (первая стадия загрузки)
+ INSTALL2_PACKAGES (инсталятор)
+ BASE_PACKAGES, BASE_LISTS, BASE_PACKAGES_REGEXP (базовая система)
+ MAIN_PACKAGES, MAIN_LISTS, MAIN_PACKAGES_REGEXP (дополнительные пакеты)
+ LIVE_PACKAGES, LIVE_LISTS, LIVE_PACKAGES_REGEXP ("живая" система)
introduced THE_{KMODULES,PACKAGES,LISTS,GROUPS} As too many things started duplicating between distros proper and (e.g. corresponding) LiveCDs, it became apparent that a class of entities which end up working for THE_USER (not a sysadmin, and not a developer, just a Linux user) is in need. So THE_KMODULES will power installed basesystem and live image, while THE_PACKAGES, THE_LISTS and THE_GROUPS will participate in building those.
2011-12-19 23:28:42 +04:00
- аналогично по модулям ядра:
implemented {THE,BASE,LIVE}_PACKAGES_REGEXP There were STAGE1_PACKAGES_REGEXP and MAIN_PACKAGES_REGEXP but adding more of those was postponed to avoid bloat and bitrot; THE_PACKAGES_REGEXP is needed for use/firmware now and looks like BASE_PACKAGES_REGEXP and LIVE_PACKAGES_REGEXP will be useful before too long either. Docs updated to include stage-specific package related vatiables.
2012-04-10 19:14:01 +04:00
+ THE_KMODULES попадут в "пользовательскую" среду (live, main)
introduced THE_{KMODULES,PACKAGES,LISTS,GROUPS} As too many things started duplicating between distros proper and (e.g. corresponding) LiveCDs, it became apparent that a class of entities which end up working for THE_USER (not a sysadmin, and not a developer, just a Linux user) is in need. So THE_KMODULES will power installed basesystem and live image, while THE_PACKAGES, THE_LISTS and THE_GROUPS will participate in building those.
2011-12-19 23:28:42 +04:00
+ STAGE1_KMODULES доступны в производных от stage2 (install2, live, rescue)
+ BASE_KMODULES попадут в установку по умолчанию
+ MAIN_KMODULES будут доступны для установки с носителя
+ LIVE_KMODULES предназначены для LiveCD/LiveFlash
full-view docs update - toplevel README received some long-needed refactoring + lowlevel detail moved, well, to lowlevel READMEs - reflected more thoroughly that m-p is not about distros anymore - dropped features.in/00example/README.en: it's already out-of-date a bit, and there's no perceived need in thorough English docs so far - wiki article got split into parts and somewhat rewritten, links updated - mv doc/{CodingStyle,style.txt}
2011-11-06 23:57:28 +04:00
По подстановкам:
introduced THE_{KMODULES,PACKAGES,LISTS,GROUPS} As too many things started duplicating between distros proper and (e.g. corresponding) LiveCDs, it became apparent that a class of entities which end up working for THE_USER (not a sysadmin, and not a developer, just a Linux user) is in need. So THE_KMODULES will power installed basesystem and live image, while THE_PACKAGES, THE_LISTS and THE_GROUPS will participate in building those.
2011-12-19 23:28:42 +04:00
- $(VAR) подставляются перед их записью в $(CONFIG), который distcfg.mk
- $$(VAR) раскрываются позже, при включении $(CONFIG) и востребовании
значений; в этом случае их значения могут изменяться до окончания
конфигурации, а также зависеть от значений других переменных
READMEs: pkglist related clarification glebfm@ asked what to do with new package lists: whether these belong to features, or to distributions themselves. This question is actually open and up for discussion but there are guidelines that can and should be written down already; and so they were. Added pkgdups utility reference as well.
2012-04-09 23:18:31 +04:00
По спискам пакетов:
- на этапе экспериментирования можно забивать прямо в описание образа
- при фиксации состояния стоит воспользоваться существующими списками,
а дополнительные оформить как можно более чётко обособленными по тем
задачам, для решения которых они и подобраны
- повторяющиеся логически связанные группы списков может иметь смысл
выделить в фичу (см., например, power или x11)
- если явной фичи не наблюдается, но у группы дистрибутивов намечается
заметная общая часть -- её можно выделить в промежуточную цель вида
distro/.name, не являющуюся самостоятельно собираемой
Reference in New Issue Copy Permalink