Mkimage/Profiles/Desktop

Что это такое?

mkimage-profiles-desktop (кратко m-p-d) — это набор профилей для сборки дистрибутивных образов на пакетной базе ALT Linux при помощи mkimage, представленный как:

• семейство git-репозиториев, поддерживаемых различными людьми (де-факто «точка сбора» — boyarsh@);
• пакеты в бранчах и дистрибутивах.

Как собрать дистрибутив?

Если рассматривать штатный для ALT Linux 4.0+ случай с использованием:

• pam_mktemp и достаточного объёма tmpfs в /tmp,
• сконфигурированного в sources.list репозитория (желательно локального или NFS-зеркала),

можно так:

mkdir -p ~/git
cd ~/git
git clone git://git.altlinux.org/people/boyarsh/packages/mkimage-profiles-desktop
cp -a ~/git/mkimage-profiles-desktop/ $TMP/mkimage-profiles-desktop/
cd $TMP/mkimage-profiles-desktop/
autoconf
./configure
nice time make rescue.cd

…и через несколько минут или полчасика при отсутствии неожиданностей образ будет готов. Список целей make можно посмотреть в Makefile.in; некоторые примеры:

make ...	получаем	проверено
rescue.cd	маленький спасательный LiveCD	mike; 20100315; 5.1; i586
live.cd	большой самостоятельный LiveCD с KDE
children.cd	большой LiveCD для маленьких
gnome.dvd	инсталяционный образ с GNOME
minimal.cd	небольшой инсталяционный образ с IceWM
school-terminal.dvd	школьный терминальный сервер	mike; 20100315; 5.1; i586

Как собрать свой дистрибутив? — читайте дальше по порядку.

Концепция

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

Реализация

дистрибутив

Итоговый образ может включать:

• средства начальной загрузки образа (stage1);
• инсталятор (install2) и/или LiveCD (live);
• пакетную базу (main, contrib);
• иное (например, rescue).

Таким компонентам соответствуют субпрофили (profiles/*).

компоненты

Создаются при сборке субпрофилей, которые:

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

особенности

Поскольку различные образы (например, инсталяционные) могут иметь одни и те же предопределённые наборы принципиальных компонент (например, stage1+install2+main), но существенно отличаться в их итоговом наполнении — предусмотрен механизм для конфигурирования путём накопления необходимых значений переменных во включаемых makefile, реализованный блоками настроек use-* в use.mk.

Дистрибутивообразующие данные «протекают» сверху вниз следующим образом:

1. умолчания: заложены разработчиком профиля на всех уровнях;
2. опции configure: заданы пользователем (релиз-менеджером);
3. Makefile: соответствие «дистрибутив-блоки», в том числе выбор субпрофилей;
4. use.mk: конфигурирование блоков;
5. profiles/*: задействование созданной конфигурации;
6. profiles/*/*scripts.d/*: нижний уровень, при возможности (и отсутствии конфигурируемости) «выселяется» в installer-feature-*.

Ознакомление

Загляните в README m-p-d; хотя бы вкратце ознакомьтесь с README.ru mkimage, куда стоит обращаться за описанием используемых в субпрофильных makefile переменных и целей сборки.

Изучение существующих примеров удобней начинать с корневого Makefile.in и далее по profiles/*/Makefile.in и profiles/pkg/lists/*. Стоит обратить внимание, что IMAGE_PACKAGES может содержать как пути ко включаемым файлам со списками имён пакетов, так и сами имена пакетов.

См. тж. местный mkimage faq.

Практика

m-p-d из профиля для сборки десктопного дистрибутива превратился в комбайн с вертикальным взлётом, позволяющий создавать широкий спектр образов и довольно неплохо масштабируемый по разработке.

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

Поэтому при добавлении use-блоков или profiles/pkg/lists/* следует по возможности изучить и повторно использовать уже существующие (в этом может помочь bin/pkgdups.sh). Также в промежутках между релизами стоит находить время и уделять внимание рефакторингу инфраструктуры; соображения по ортогонализации профиля и наследованию дистрибутивообразующих переменных можно почитать здесь.

Модификация

используя уже существующее

Если создаётся вариация на тему уже существующего вида — например, десктопный инсталер — может оказаться достаточным скомбинировать уже существующие цели use-* из подключаемой библиотеки use.mk в одной строчке, добавленной в корневой Makefile.in. Например, так можно добавить rescue к понравившемуся дистрибутиву, собранному без него.

с добавлением новых блоков

Например, потребовался ещё не описанный десктопный инсталер с LXDE; для подготовки к его сборке может оказаться достаточным:

1. создать список пакетов (например, profiles/pkg/lists/lxde);
2. добавить строчку с описанием дистрибутива в корневой Makefile.in:
   

   lxde.cd: | use-lxde use-xdm install2 main install-cd.@IMAGETYPE@</tt>

При этом необязательно явно описывать «мостик» между именем списка пакетов (lxde) и промежуточной целью (use-lxde) в подключаемой библиотеке use.mk: тривиальные случаи обрабатываются шаблоном use-%, который вносит «прилетевшее» имя в списки для субпрофилей main и live в предположении, что это название пакаджлиста — тем самым обеспечивая его «подхватывание» при сборке как образа дистрибутива для инсталяции, так и LiveCD.

синхронизация

Дистрибутивы — штука сложная. В одиночку их делать можно, но довольно тяжело. Поэтому лучше пользоваться уже существующими наработками: даже если на их освоение придётся потратить некоторое время, их переизобретение также не дастся даром. Также хорошо стараться делать правки так, чтобы не понижать универсальность профиля, не исходя из предположения «да мне только под свой дистрибутив заточить»: внесение наработок в апстрим может помочь снизить затраты времени на поддержание своей ветки.

Обсуждение масштабных переработок профилей релиз-менеджерами производится в рассылке devel-distro@. Обратите внимание на то, что хотя бы кратенько анонсировать предполагаемые изменения лучше до их реализации, чтобы иметь возможность получить их оценку другими участниками и

• избежать непредвиденных последствий;
• доставить другим минимум неудобств при втягивании изменений.

Ссылки

• mkimage
• бранчи
• инсталятор
• компоненты инсталятора
• устаревшая ветка этой страницы