Mkimage/Profiles/Desktop

Материал из ALT Linux Wiki
готовим релиз

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

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

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

Зачем может пригодиться?

  • релиз-менеджеры (те, кто выпускает дистрибутивы) используют профили, чтобы укомплектовать и собрать из пакетной базы и информации в профиле пригодный к использованию образ — например, инсталятор или LiveFlash;
  • системным администраторам бывает удобно вносить свои небольшие изменения для минимизации действий после типичной установки дистрибутива;
  • нормальным людям может быть удобней собирать образы локально из пакетов на зеркале, чем тащить исошки.

При отсутствии локального зеркала какого-либо бранча или сизифа эксперименты может быть лучше отложить, потому как трафик.

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

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

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

можно так:

mkdir -p ~/git
cd ~/git
git clone git://git.altlinux.org/people/boyarsh/packages/mkimage-profiles-desktop
git checkout p5
autoconf
./configure
mkdir /tmp/mkimage-work-dir
TMP=/tmp/mkimage-work-dir nice time make rescue.cd

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

make ... получаем проверено (на репо[4])
rescue.cd маленький спасательный LiveCD 20100315 mike (5.1/i586)
live.cd большой самостоятельный LiveCD с KDE 20100315 mike (5.1/x86_64)
gnome.dvd инсталяционный образ с GNOME 20100315 mike (p5/x86_64)
minimal.cd небольшой инсталяционный образ с IceWM 20100315 mike (Sisyphus/x86_64)
school-terminal.dvd школьный терминальный сервер 20100315 mike (p5/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.in в одной строчке, добавленной в корневой Makefile.in. Например, так можно добавить rescue к понравившемуся дистрибутиву, собранному без него.

В частности, как подправить список пакетов:

  • совсем «крупноблочно» — в Makefile.in для нужной цели
на уровне того же «добавить rescue» или «включить icewm»
  • более тонко — в use.mk.in
на уровне «добавить пакаджлист», хотя можно и индивидуальные в различные стадии добавлять
  • совсем тонко — в profiles/pkg/lists/*, используемых для сборки желаемого образа
выясняются на предыдущих уровнях

Выяснить точный список попадающих в дистрибутив списков бывает неудобно (приходится изучать сгенерированные stage-autocfg.mk в субпрофилях); также рекомендуется сохранять лог сборки с VERBOSE=1, чтоб иметь возможность анализировать состав.

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

Например, потребовался ещё не описанный десктопный инсталер с 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@[5]. Обратите внимание на то, что хотя бы кратенько анонсировать предполагаемые изменения лучше до их реализации, чтобы иметь возможность получить их оценку другими участниками и

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

Разумеется, для удобного отсмотра изменений и обмена ими стоит использовать git и аккуратно оформлять коммиты.

Ссылки

Примечания

  1. если нет цели посмотреть именно дистрибутивный профиль, лучше сразу в git
  2. текущая версия mkimage (проверено на 0.1.3) умеет делать workdir’ы на tmpfs вне каталога профиля, но всё-таки лучше собирать из отдельной копии во избежание случайных коммитов мусора (подставленных autoconf .in-файлов, не добавленных в .gitignore, и т. п.).
  3. mkimage используется начиная с 4.0/branch и до Sisyphus; со старыми ветками — M40, M41 — и соответствующими профилями возможны старые грабли
  4. Сборка на Sisyphus обычно из бранча master профиля, на 5.1/branch либо p5/branch -- p5.
  5. подписывает mike@ по запросу