Mkimage/Profiles/Desktop: различия между версиями
м (→Как собрать дистрибутив?: это уже отабличено) |
Andyc (обсуждение | вклад) (корректная ссылка boyarsh@) |
||
Строка 4: | Строка 4: | ||
== Что это такое? == | == Что это такое? == | ||
<tt>mkimage-profiles-desktop</tt> (кратко ''m-p-d'') — это набор профилей для сборки дистрибутивных образов на пакетной базе ALT Linux при помощи [[mkimage]], представленный как: | <tt>mkimage-profiles-desktop</tt> (кратко ''m-p-d'') — это набор профилей для сборки дистрибутивных образов на пакетной базе ALT Linux при помощи [[mkimage]], представленный как: | ||
* семейство git-репозиториев, поддерживаемых различными людьми (де-факто «точка сбора» — [http://git.altlinux.org/people/boyarsh/packages/?p=mkimage-profiles-desktop boyarsh@]); | * семейство git-репозиториев, поддерживаемых различными людьми (де-факто «точка сбора» — [http://git.altlinux.org/people/boyarsh/packages/?p=mkimage-profiles-desktop.git;a=summary boyarsh@]); | ||
* пакеты в бранчах и дистрибутивах<ref>если нет цели посмотреть именно дистрибутивный профиль, лучше сразу в git</ref>. | * пакеты в бранчах и дистрибутивах<ref>если нет цели посмотреть именно дистрибутивный профиль, лучше сразу в git</ref>. | ||
Версия от 10:40, 20 марта 2010
Что это такое?
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-зеркала),
можно так:
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/
git checkout p5
autoconf
./configure
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.
Дистрибутивообразующие данные «протекают» сверху вниз следующим образом:
- умолчания: заложены разработчиком профиля на всех уровнях;
- опции configure: заданы пользователем (релиз-менеджером);
- Makefile: соответствие «дистрибутив-блоки», в том числе выбор субпрофилей;
- use.mk: конфигурирование блоков;
- profiles/*: задействование созданной конфигурации;
- 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; для подготовки к его сборке может оказаться достаточным:
- создать список пакетов (например, profiles/pkg/lists/lxde);
- добавить строчку с описанием дистрибутива в корневой 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
- ↑ текущая версия mkimage (проверено на 0.1.3) умеет делать workdir’ы на tmpfs вне каталога профиля, но всё-таки лучше собирать из отдельной копии во избежание случайных коммитов мусора (подставленных autoconf .in-файлов, не добавленных в .gitignore, и т. п.).
- ↑ mkimage используется начиная с 4.0/branch и до Sisyphus; со старыми ветками — M40, M41 — и соответствующими профилями возможны старые грабли
- ↑ Сборка на Sisyphus обычно из бранча master профиля, на 5.1/branch либо p5/branch -- p5.
- ↑ подписывает ktirf@ по запросу