Mkimage-profiles/howto

Зачем и для кого?

Это руководство по созданию производных дистрибутивов может оказаться полезно тем, кого почти устраивают уже существующие и при этом есть свои замечания или пожелания — начиная с обоев по умолчанию и добавления своих пакетов. :)

Предполагается хотя бы шапочное знакомство с mkimage-profiles.

Одноразовая корректировка

Перед внесением правок стоит удостовериться, что mkimage установлен, а выбранный базовый дистрибутив им собирается и после этого работает; пожалуйста, не пропустите страничку с примерами, чтоб не тратить впустую время на экспериментальное выяснение уже описанного там и в QUICKSTART.

Проверка

Возьмём для начала live-icewm.iso — простой самогруз с лёгким оконным менеджером IceWM, хорошо подходящим как для небыстрого оборудования, так и для полукиосков заданной функциональности. Его сборка должна пройти успешно в течение нескольких минут (до получаса на сколь-нибудь современном процессоре) после команды:

$ make live-icewm.iso

По умолчанию сборка производится под «родную» архитектуру хоста с использованием системной конфигурации apt. Если что-то произойдёт не так — например, отсутствует mkimage, не настроен hasher или автонаходилка не нашла места для сборки — должна быть выдана относительно внятная диагностика.

В случае успешной сборки должна появиться строчка, указывающая путь к собранному образу и его размер:

** image: ~/out/live-icewm-20120717-i586.iso [173M]

Этот образ можно проверить в виртуальной машине, указав его в качестве загрузочного носителя для VirtualBox либо воспользовавшись kvm или qemu:

$ kvm -cdrom ~/out/live-icewm-20120717-i586.iso

Загрузился? Неужто :)

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

$ ls -F1 build/
build.log          -- журнал сборки
distcfg.mk         -- конфигурационный файл
files/             -- содержимое копируется в корень образа
functions.mk       -- полезности
image-scripts.d/   -- см. документацию mkimage
lib/               -- содержимое включается в Makefile 
live/              -- субпрофиль для сборки LiveCD
Makefile           -- основной файл для сборки
out@               -- ссылка на каталог с результатом
pkg/               -- списки пакетов, файлы групп
README             -- стоит глянуть, там немного :)
scripts.d/         -- см. документацию mkimage
sources.list       -- создаётся метапрофилем для архива
squashcfg.mk       -- передаваемые между stage1/2 данные
stage1/            -- субпрофиль с загрузчиками ядра и второй стадии
vars.mk            -- вспомогательный makefile для дампа переменных

Во включаемом в build/live/Makefile файле build/live/stage2cfg.mk заметно, какие переменные влияют на состав пакетной базы формирующего LiveCD субпрофиля; из них наиболее употребимы THE_PACKAGES и THE_LISTS (см. тж. conf.d/README).

Заполняются эти переменные в build/distcfg.mk; посмотреть окончательные значения, принятые в сборку, можно в build/build.log после её завершения. Содержимое *_LISTS трактуется как имена файлов со списками имён пакетов, расположенных ниже build/pkg/lists.

Правка

Например, поменяем браузер с firefox на chromium:

$ cd build
$ grep -r firefox distcfg.mk pkg/lists
pkg/lists/tagged/desktop+network:firefox
$ sed -i 's/firefox/chromium/' pkg/lists/tagged/desktop+network

Таким образом, для модификации пакетной базы можно просто добавить или убрать нужное в конфигурационном файле и списках пакетов, после чего запустить в сборочном каталоге команду make — отработав, она должна выдать ту же строчку с информацией по собранному ISO (в случае повторной сборки может понадобиться предварительно выполнить make distclean):

$ make distclean all
[...]
Total directory bytes: 16384
Path table size(bytes): 52
Max brk space used 19000
93071 extents written (181 MB)
** image: /home/mike/out/live-icewm-20120718-i586.iso [182M]
IMAGE_OUTPATH = /home/mike/out/live-icewm-20120718-i586.iso
IMAGE_OUTFILE = live-icewm-20120718-i586.iso

Что дальше

Если в результате правок желаемый результат был полностью достигнут, можно заархивировать полученный профиль после distclean и на этом с ним закончить, используя полученный образ.

В случае же наличия желания поделиться наработками с коллегами — что может пригодиться в будущем, когда не придётся делать те же правки поверх следующей версии, ведь они уже включены — можно прислать мне (mike@altlinux.org) полученный патч, закоммитив изменения и прибавив описание их предназначения:

$ git diff
diff --git a/pkg/lists/tagged/desktop+network b/pkg/lists/tagged/desktop+network
index dbfb8f9..104b6b0 100644
--- a/pkg/lists/tagged/desktop+network
+++ b/pkg/lists/tagged/desktop+network
@@ -1 +1 @@
-firefox
+seamonkey
$ git commit -am 'desktop+network: replaced firefox with seamonkey'
[master daef2b2] desktop+network: replaced firefox with seamonkey
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git format-patch HEAD^
0001-desktop-network-replaced-firefox-with-seamonkey.patch

Обобщаем в метапрофиль

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

Например, патч с заменой firefox на seamonkey в pkg.in/lists/tagged/desktop+network будет идентичен вышеприведённому, но в апстрим он попадёт только в случае признания именно Seamonkey рекомендуемым браузером производства Mozilla.

Поэтому придётся оценивать, в каком месте и как произвести требуемое изменение.

Таких мест есть несколько (это наши объекты):

• прямое указание в *_PACKAGES для своего дистрибутива;
• создание и применение отдельного пакаджлиста, если добавляется взаимосвязанная группа пакетов;
• описание «технической» или собираемой дистрибутивной цели, добавляющей такой пакет или пакаджлист.

Пример замены firefox на seamonkey для mkimage-profiles > 0.7.4 — изменяется файл conf.d/live.mk:

distro/live-seamonkey: distro/live-icewm
        @$(call add,LIVE_PACKAGES,firefox- seamonkey)

Используется синтаксис GNU make, так что читаются эти две строчки таким образом:

• цель distro/live-seamonkey зависит от цели distro/live-icewm (то есть последняя должна быть выполнена, чтобы приступить к выполнению первой);
• «рецепт» действий содержит вызов функции add с параметрами «LIVE_PACKAGES» и «firefox- seamonkey».

Если при этом требуется удаление какого-либо пакета — стоит проследить, где именно при построении конфигурации дистрибутива он появляется, и обсудить в devel-distro@ варианты внесения корректировки. Для взятого примера цепочка выглядит так (можно добавить при сборке REPORT=1 и просмотреть полученный targets.png):

1. distro/live-icewm
2. distro/.live-desktop
3. +live = use/live/desktop
4. @$(call add,LIVE_LISTS,$(call tags,desktop && (live || network)))
5. pkg.in/lists/tagged/desktop+network

При этом цель distro/.live-desktop используется как основа для всех «более-менее пользовательских» LiveCD, а цель use/live/desktop описана достаточно объёмно для того, чтобы форкать её целиком; может иметь смысл обсудить следующий вариант переработки:

use/live/.desktop: use/live/base use/x11/wacom use/live/sound +vmguest +power
        @$(call add,LIVE_LISTS,$(call tags,desktop live))
        @$(call add,LIVE_LISTS,$(call tags,base l10n))
        @$(call add,LIVE_PACKAGES,fonts-ttf-dejavu fonts-ttf-droid)
        @$(call add,SYSLINUX_CFG,localboot)

use/live/desktop: use/live/.desktop
        @$(call add,LIVE_LISTS,$(call tags,desktop network))

…тогда «публичное API» в виде use/live/desktop останется неизменным, но появится возможность использовать его большую часть, но не полный блок конфигурации, поставив зависимость от use/live/.desktop.

Следует заметить, что одной из основных идей метапрофиля является возможность комбинирования «неопределённости в заданном направлении» (часть задачи, формулируемая примерно как «нужен livecd») и точности в том, где есть конкретные требования (например, «firefox версии 10»). Выражается это в том, что можно основываться на уже существующих образах и фичах либо построить всё почти с нуля; можно брать существующие списки пакетов, а можно жёстко задать свои. Разумный баланс (точнее, его пределы) для каждого образа могут быть свои, но как общее правило — для «любительских» проектов и семейств образов стоит смелей пользоваться наследованием, а вот «ответственные» образы может быть лучше конфигурировать с явным заданием необходимой пакетной базы (и в будущем — юнит-тестов, которые надо утащить из m-p-d).

[to be continued]