mkimage-profiles

History

Michael Shigorin a36d0236a4 stage1, stage2: initial modlists support stage1's got prepare-modules target collecting modules file snippets all over stage1/modules.d/ subdirectories within individual features. stage2 now adds names of all the features going into a particular image as snippet file suffix list so that individual features don't have to register themselves twice (as a feature and as a propagator modules.d snippet carrier). This is going to allow both "uncommon" modules getting included with no problem (sin@ has wanted cifs ones for quite some time, for example, and some want e.g. infiniband modules) and to reduce the actual list below the common mark as well (which is the case with live-privacy image, for one). And stage1 memory consumption does matter in some cases as it's highly critical with no chance to use swap yet.		2015-04-20 13:35:24 +03:00
..
main	fix kpackages() API	2014-09-19 20:53:25 +04:00
rootfs	rootfs: README update	2014-08-27 22:30:14 +04:00
stage1	stage1, stage2: initial modlists support	2015-04-20 13:35:24 +03:00
stage2	stage2, install2: oops, narrow the cleanup back	2015-03-10 00:00:09 +03:00
Makefile	initial rootfs subprofile and services feature	2013-06-17 14:03:53 +04:00
README	documentation: use paths relative to toplevel dir	2014-03-05 21:36:30 +04:00

README

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.

== sub.in ==

Этот каталог содержит субпрофили; содержимое затребованных
(названия которых содержатся в значении переменной SUBPROFILES,
которую заполняют цели sub/* -- см. lib/sugar.mk) будет
скопировано в корневой каталог формируемого профиля.

Просьба ответственно относиться к изменению существующих субпрофилей
и вдумчиво -- к созданию новых; возможно, достаточно всего лишь
оформить нужное новой фичей (см. features.in/).

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

Краткое описание существующих вариантов (см. соотв. README):

* rootfs является особым случаем, который используется при
  формировании файловых систем, предназначенных для пользователя
  (т.е. корень LiveCD, образа VM, ...)

* stage1: propagator и загрузчик (совместно с фичей syslinux);
  типично требуется для инсталяторов, live- и rescue-образов,
  но может использоваться без добавления таковых в образ,
  обеспечивая сетевую загрузку второй стадии

* stage2: наиболее сложный технологически субпрофиль, поскольку
  он является только базовым для получения ряда итоговых частей
  дистрибутива (install2, live, rescue); задействуется для этого
  только опосредованно через use/stage2/* и модифицирует stage1
  в силу наличия связи между ними (в stage1 попадает образ ядра
  и firmware, в stage2 -- соответствующие модули)

* main: пакетная база, укладываемая на образ (NB: поскольку рабочий
  чрут в этом случае не содержит ничего, кроме пакетов, добавлять
  что-либо в image-scripts.d смысла нет, только в scripts.d)

README Unescape Escape

README