Mkimage/Profiles/Desktop: различия между версиями

Материал из ALT Linux Wiki
м (+img)
(не показано 26 промежуточных версий 5 участников)
Строка 3: Строка 3:
[[File:Carving_the_roast.png‎||right|готовим релиз]]
[[File:Carving_the_roast.png‎||right|готовим релиз]]
== Что это такое? ==
== Что это такое? ==
<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>.
 
== Зачем может пригодиться? ==
* ''релиз-менеджеры'' (те, кто выпускает дистрибутивы) используют профили, чтобы укомплектовать и собрать из пакетной базы и информации в профиле пригодный к использованию образ — например, инсталятор или LiveFlash;
* ''системным администраторам'' бывает удобно вносить свои небольшие изменения для минимизации действий после типичной установки дистрибутива;
* ''нормальным людям'' может быть удобней собирать образы локально из пакетов на зеркале, чем тащить исошки.
 
При отсутствии локального зеркала какого-либо бранча или сизифа эксперименты может быть лучше отложить, потому как трафик.


== Как собрать дистрибутив? ==
== Как собрать дистрибутив? ==
Если рассматривать штатный для ALT Linux 4.0+ случай с использованием:
Если рассматривать штатный для ALT Linux 4.0+ случай с использованием:
* [[pam_mktemp]] и достаточного объёма [[tmpfs]] в <tt>/tmp</tt><ref>NB: текущая версия <tt>mkimage</tt> (проверено на 0.1.3) умеет делать workdir’ы на tmpfs вне каталога профиля, но всё-таки лучше собирать из отдельной копии во избежание случайных коммитов мусора (подставленных <tt>autoconf</tt> .in-файлов и т. п.).</ref>,
* [[pam_mktemp]] и достаточного объёма [[tmpfs]] в <tt>/tmp</tt><ref>текущая версия <tt>mkimage</tt> (проверено на 0.1.3) умеет делать workdir’ы на tmpfs вне каталога профиля, но всё-таки лучше собирать из отдельной копии во избежание случайных коммитов мусора (подставленных <tt>autoconf</tt> .in-файлов, не добавленных в <tt>.gitignore</tt>, и т. п.).</ref>,
* сконфигурированного в <tt>sources.list</tt> репозитория<ref>mkimage используется начиная с 4.0/branch и до Sisyphus; со старыми ветками — M40, M41 — и соответствующими профилями возможны [[Mkimage/Desktop/OldTroubles|старые грабли]]</ref> (желательно локального или NFS-[[Mirror|зеркала]]),
* сконфигурированного в <tt>sources.list</tt> репозитория<ref>mkimage используется начиная с 4.0/branch и до Sisyphus; со старыми ветками — M40, M41 — и соответствующими профилями возможны [[Mkimage/Desktop/OldTroubles|старые грабли]]</ref> (желательно локального или NFS-[[Mirror|зеркала]]),
* настроенного для текущего пользователя [[Hasher/Краткое_руководство|hasher]],
можно так:
можно так:
<source lang="bash">
<source lang="bash">
Строка 16: Строка 24:
cd ~/git
cd ~/git
git clone git://git.altlinux.org/people/boyarsh/packages/mkimage-profiles-desktop
git clone git://git.altlinux.org/people/boyarsh/packages/mkimage-profiles-desktop
cp -a ~/git/mkimage-profiles-desktop/ $TMP/mkimage-profiles-desktop/
git checkout p5
cd $TMP/mkimage-profiles-desktop/
autoconf
autoconf
./configure
./configure
make rescue.cd
mkdir /tmp/mkimage-work-dir
TMP=/tmp/mkimage-work-dir nice time make rescue.cd
</source>
</source>
…и через несколько минут или полчасика при отсутствии [[Mkimage/debug|неожиданностей]] образ будет готов<ref>Проверено mike@ 12.12.2009 на 5.1/branch (x86_64)</ref>.
…и через несколько минут или полчасика при отсутствии [[Mkimage/debug|неожиданностей]] образ будет готов.  Список целей {{cmd|make}} можно посмотреть в {{path|Makefile.in}}; некоторые примеры:
 
{|border="1" cellpadding="5" cellspacing="0"
|-
! make ...
! получаем
! проверено (на репо<ref>Сборка на Sisyphus обычно из бранча <tt>master</tt> профиля, на 5.1/branch либо p5/branch -- <tt>p5</tt>.</ref>)
|-
| rescue.cd
| маленький спасательный LiveCD
| 20100315 mike (5.1/i586)
|-
| live.cd
| большой самостоятельный LiveCD с KDE
| 20100315 mike (5.1/x86_64)
<!--|-
| children.cd
| большой LiveCD для маленьких
| 20100315 mike (p5/i586) облом: нет branding-altlinux-children-release -->
|-
| gnome.dvd
| инсталяционный образ с GNOME
| 20100315 mike (p5/x86_64)
|-
| minimal.cd
| небольшой инсталяционный образ с IceWM
| 20100315 mike (Sisyphus/x86_64)
|-
| school-terminal.dvd
| школьный терминальный сервер
| 20100315 mike (p5/i586)
|}


Как собрать ''свой'' дистрибутив? — читайте дальше по порядку.
=== а ''свой'' как? ===
Читайте дальше по порядку.  Только это уже '''для терпеливых'''.


== Концепция ==
== Концепция ==
Строка 46: Строка 86:


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


Дистрибутивообразующие данные «протекают» сверху вниз следующим образом:
Дистрибутивообразующие данные «протекают» сверху вниз следующим образом:
Строка 59: Строка 99:
Загляните в [http://git.altlinux.org/people/boyarsh/packages/?p=mkimage-profiles-desktop.git;a=blob;f=README;hb=HEAD README] m-p-d; хотя бы вкратце ознакомьтесь с [http://git.altlinux.org/people/legion/packages/?p=mkimage.git;a=blob;f=doc/README.ru;hb=HEAD README.ru] mkimage, куда стоит обращаться за описанием используемых в субпрофильных makefile переменных и целей сборки.
Загляните в [http://git.altlinux.org/people/boyarsh/packages/?p=mkimage-profiles-desktop.git;a=blob;f=README;hb=HEAD README] m-p-d; хотя бы вкратце ознакомьтесь с [http://git.altlinux.org/people/legion/packages/?p=mkimage.git;a=blob;f=doc/README.ru;hb=HEAD README.ru] mkimage, куда стоит обращаться за описанием используемых в субпрофильных makefile переменных и целей сборки.


Изучение существующих примеров удобней начинать с корневого <tt>[http://git.altlinux.org/people/boyarsh/packages/?p=mkimage-profiles-desktop.git;a=blob;f=Makefile.in;hb=HEAD Makefile.in]</tt> и далее по <tt>profiles/*/Makefile.in</tt> и <tt>profiles/pkg/lists/*</tt>. Стоит обратить внимание, что <tt>IMAGE_PACKAGES</tt> может содержать как пути ко включаемым файлам со списками имён пакетов, так и сами имена пакетов.
Изучение существующих примеров удобней начинать с корневого <tt>[http://git.altlinux.org/people/boyarsh/packages/?p=mkimage-profiles-desktop.git;a=blob;f=Makefile.in;hb=HEAD Makefile.in]</tt> и далее по <tt>profiles/*/Makefile.in</tt> и <tt>profiles/pkg/lists/*</tt>. Стоит иметь в виду, что <tt>IMAGE_PACKAGES</tt> может содержать как пути ко включаемым файлам со списками имён пакетов, так и сами имена пакетов.


См. тж. местный [[Mkimage/FAQ|mkimage faq]].
См. тж. местный [[Mkimage/FAQ|mkimage faq]].
Строка 73: Строка 113:


=== используя уже существующее ===
=== используя уже существующее ===
Если создаётся вариация на тему уже существующего вида — например, десктопный инсталер — может оказаться достаточным скомбинировать уже существующие цели <tt>use-*</tt> из подключаемой библиотеки <tt>use.mk</tt> в одной строчке, добавленной в корневой <tt>Makefile.in</tt>. Например, так можно добавить rescue к понравившемуся дистрибутиву, собранному без него.
Если создаётся вариация на тему уже существующего вида — например, десктопный инсталер — может оказаться достаточным скомбинировать уже существующие цели <tt>use-*</tt> из подключаемой библиотеки {{path|use.mk.in}} в одной строчке, добавленной в корневой {{path|Makefile.in}}. Например, так можно добавить rescue к понравившемуся дистрибутиву, собранному без него.
 
В частности, как подправить список пакетов:
* совсем «крупноблочно» — в {{path|Makefile.in}} для нужной цели
: на уровне того же «добавить rescue» или «включить icewm»
* более тонко — в {{path|use.mk.in}}
: на уровне «добавить пакаджлист», хотя можно и индивидуальные в различные стадии добавлять
* совсем тонко — в {{path|profiles/pkg/lists/*}}, используемых для сборки желаемого образа
: выясняются на предыдущих уровнях
 
Выяснить точный список попадающих в дистрибутив списков бывает неудобно (приходится изучать сгенерированные {{path|stage-autocfg.mk}} в субпрофилях); также рекомендуется сохранять лог сборки с <tt>VERBOSE=1</tt>, чтоб иметь возможность анализировать состав.


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


Обсуждение масштабных переработок профилей релиз-менеджерами производится в рассылке [https://lists.altlinux.org/mailman/listinfo/devel-distro devel-distro@]<ref>подписывает ktirf@ по запросу</ref>. Обратите внимание на то, что хотя бы кратенько анонсировать предполагаемые изменения лучше ''до'' их реализации, чтобы иметь возможность получить их оценку другими участниками и
Обсуждение масштабных переработок профилей релиз-менеджерами производится в рассылке [https://lists.altlinux.org/mailman/listinfo/devel-distro devel-distro@]<ref>подписывает mike@ по запросу</ref>. Обратите внимание на то, что хотя бы кратенько анонсировать предполагаемые изменения лучше ''до'' их реализации, чтобы иметь возможность получить их оценку другими участниками и
* избежать непредвиденных последствий;
* избежать непредвиденных последствий;
* доставить другим минимум неудобств при втягивании изменений.
* доставить другим минимум неудобств при втягивании изменений.
Разумеется, для удобного отсмотра изменений и обмена ими стоит использовать [[git]] и аккуратно оформлять коммиты.


== Ссылки ==
== Ссылки ==
Строка 95: Строка 147:
* [[Installer/beans|компоненты инсталятора]]
* [[Installer/beans|компоненты инсталятора]]
* [[Mkimage/Desktop|устаревшая ветка этой страницы]]
* [[Mkimage/Desktop|устаревшая ветка этой страницы]]
* [http://forum.altlinux.org/index.php/topic,3321.msg102218.html#msg102218 пошаговые инструкции]
* [https://forum.altlinux.org/index.php?topic=40191.msg102218#msg102218 Небольшая инструкция по самостоятельной сборке дистрибутивов на базе бранча 5.1]
* [http://sites.google.com/site/alteduspb/publications-and-reports/livecd-cookbook.odt?attredirects=0&d=1 Пример сборки своего LiveCD (документ .odt)]
* [["Введение в сборку дистрибутивов"]]
* [http://fly.osdn.org.ua/~mike/ALT/docs/whitelabel/whitelabel-packages.png Иллюстрация к спискам пакетов] <small>(несколько устаревшая, читать <tt>profiles/pkg/lists/</tt> и <tt>profiles/pkg/groups/</tt>)</small>
* [http://lists.altlinux.org/pipermail/devel-conf/2007-October/007496.html про pkg/groups и alterator-pkg]


== Примечания ==
== Примечания ==

Версия от 15:15, 11 октября 2017

готовим релиз

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

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@ по запросу