Mkimage-profiles/howto: различия между версиями

Материал из ALT Linux Wiki
м (→‎Одноразовая корректировка: базовая версия m-p)
 
(не показано 27 промежуточных версий 3 участников)
Строка 2: Строка 2:
Это руководство по созданию производных дистрибутивов может оказаться полезно тем, кого почти устраивают уже существующие и при этом есть свои замечания или пожелания — начиная с обоев по умолчанию и добавления своих пакетов. :)
Это руководство по созданию производных дистрибутивов может оказаться полезно тем, кого почти устраивают уже существующие и при этом есть свои замечания или пожелания — начиная с обоев по умолчанию и добавления своих пакетов. :)


= Для начала =
Предполагается хотя бы шапочное знакомство с [[mkimage-profiles]], включая описание [[Mkimage/Profiles/m-p/objects|объектов]], и базовые навыки работы в командной строке).
 
Для сборки без установки системы на базе ALT можно задействовать [[Starterkits/builder|сборочный стартеркит]] — LiveCD со всем нужным (включая настроенный {{pkg|hasher}} и установленный пакет {{pkg|mkimage-profiles}}), который можно запустить на временно свободном железе или в виртуалке с доступом в интернет (пакеты будут загружаться с публичного сервера).
 
= Одноразовая корректировка =
Перед внесением правок стоит удостовериться, что [[mkimage]] установлен, а выбранный базовый дистрибутив им собирается и после этого работает; пожалуйста, не пропустите страничку с [[Mkimage/Profiles/m-p/examples|примерами]], чтоб не тратить впустую время на экспериментальное выяснение уже описанного там и в {{path|QUICKSTART}}.
Перед внесением правок стоит удостовериться, что [[mkimage]] установлен, а выбранный базовый дистрибутив им собирается и после этого работает; пожалуйста, не пропустите страничку с [[Mkimage/Profiles/m-p/examples|примерами]], чтоб не тратить впустую время на экспериментальное выяснение уже описанного там и в {{path|QUICKSTART}}.


= Проверка =
Если предполагаете собирать дистрибутив на ином репозитории, нежели текущая [[branches|стабильная ветка]] -- стоит ориентироваться на версию (по крайней мере ветку) [http://packages.altlinux.org/mkimage-profiles пакета] mkimage-profiles в нём; в т.ч. и при работе с [http://git.altlinux.org/gears/m/mkimage-profiles.git mkimage-profiles.git].
Возьмём для примера live-icewm.iso — простой самогруз с лёгким оконным менеджером IceWM, хорошо подходящим как для небыстрого оборудования, так и для полукиосков заданной функциональности. Его сборка должна пройти успешно в течение нескольких минут (до получаса на сколь-нибудь современном процессоре) после команды<ref>подразумевается, что мы работаем со свежей копией mkimage-profiles.git, находясь в соответствующем каталоге</ref>:
 
{{attention|Ни в коем разе не запускайте сборку от имени root!<br /><tt>hasher-priv: caller has invalid uid: 0</tt>}}
 
== Проверка ==
Возьмём для начала live-icewm.iso — простой самогруз с лёгким оконным менеджером IceWM, хорошо подходящим как для небыстрого оборудования, так и для полукиосков заданной функциональности. Его сборка должна пройти успешно в течение нескольких минут (до получаса на сколь-нибудь современном процессоре) после команды<ref>подразумевается, что мы работаем со свежей копией mkimage-profiles.git, находясь в соответствующем каталоге</ref>:
  $ make live-icewm.iso
  $ make live-icewm.iso


Строка 12: Строка 20:


В случае успешной сборки должна появиться строчка, указывающая путь к собранному образу и его размер:
В случае успешной сборки должна появиться строчка, указывающая путь к собранному образу и его размер:
  ** image: ~/out/live-icewm-20120717-i586.iso [173M]
  '''** image: ~/out/live-icewm-20120717-i586.iso [173M]'''


Этот образ можно проверить в виртуальной машине, указав его в качестве загрузочного носителя для VirtualBox либо воспользовавшись kvm<ref>требует {{cmd|modprobe kvm_intel}} или {{cmd|modprobe kvm_amd}} сообразно процессору, а также группу <tt>vmusers</tt> для доступа к {{path|/dev/kvm}}</ref> или qemu:
Этот образ можно проверить в виртуальной машине, указав его в качестве загрузочного носителя для VirtualBox либо воспользовавшись kvm<ref>требует {{cmd|modprobe kvm_intel}} или {{cmd|modprobe kvm_amd}} сообразно процессору (см. тж. сервис <tt>qemu-kvm</tt>), а также группу <tt>vmusers</tt> для доступа к {{path|/dev/kvm}}</ref> или qemu:
  $ kvm -cdrom ~/out/live-icewm-20120717-i586.iso
  $ kvm -m 1024 -cdrom ~/out/live-icewm-20120717-i586.iso


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


Также при этом в каталоге {{path|mkimage-profiles}} появится ссылка {{path|build}}, указывающая на сборочный каталог со сгенерированным минимальным профилем, который должно быть проще осмотреть целиком.  Рассмотрим его подробней:
Также при этом в каталоге {{path|mkimage-profiles}} появится ссылка {{path|build}}, указывающая на сборочный каталог со сгенерированным минимальным профилем, который должно быть проще осмотреть целиком.  Приступим:
<pre>
 
$ ls -F1 build/
$ ls -F1 build/
build.log          -- журнал сборки
build.log          -- журнал сборки
distcfg.mk        -- конфигурационный файл — его и правим
'''distcfg.mk        -- конфигурационный файл'''
files/            -- содержимое копируется в корень образа
files/            -- содержимое копируется в корень образа
functions.mk      -- полезности
functions.mk      -- полезности
image-scripts.d/  -- см. документацию mkimage
image-scripts.d/  -- см. документацию mkimage
lib/              -- содержимое включается в Makefile  
lib/              -- содержимое включается в Makefile  
live/              -- субпрофиль для сборки LiveCD — нам сюда
'''live/              -- субпрофиль для сборки LiveCD'''
Makefile          -- основной файл для сборки
Makefile          -- основной файл для сборки
out@              -- ссылка на каталог с результатом
out@              -- ссылка на каталог с результатом
pkg/              -- списки пакетов, файлы групп — ...и сюда
'''pkg/              -- списки пакетов, файлы групп'''
README            -- стоит глянуть, там немного :)
'''README            -- стоит глянуть, там немного :)'''
scripts.d/        -- см. документацию mkimage
scripts.d/        -- см. документацию mkimage
sources.list      -- создаётся метапрофилем для архива
sources.list      -- создаётся метапрофилем для архива
squashcfg.mk      -- передаваемые между stage1/2 данные
squashcfg.mk      -- передаваемые между stage1/2 данные
stage1/            -- субпрофиль с загрузчиками ядра и второй стадии
stage1/            -- субпрофиль с загрузчиками ядра и второй стадии
vars.mk            -- вспомогательный makefile для дампа переменных
vars.mk            -- вспомогательный makefile для дампа переменных
</pre>
 
Во включаемом в {{path|build/live/Makefile}} файле {{path|build/live/stage2cfg.mk}} заметно, какие переменные влияют на состав пакетной базы формирующего LiveCD субпрофиля; из них наиболее употребимы <tt>THE_PACKAGES</tt> и <tt>THE_LISTS</tt> (см. тж. {{path|conf.d/README}}).
 
Заполняются эти переменные в {{path|build/distcfg.mk}}; посмотреть окончательные значения, принятые в сборку, можно в {{path|build/build.log}} после её завершения<ref>для тестового прогона можно добавить опцию <tt>CHECK=1</tt>, см. {{path|doc/params.txt}}</ref>.  Содержимое <tt>*_LISTS</tt> трактуется как имена файлов со списками имён пакетов, расположенных ниже {{path|build/pkg/lists}}.
 
При сборке с добавлением в параметры {{cmd|make}} <tt>REPORT=1</tt> и наличии {{pkg|graphviz}} будет собрана визуализация графа зависимостей между промежуточными целями {{pkg|make}}:
 
$ make REPORT=1 live-icewm.iso
[...]
'''** target graph report: build/reports/targets.png'''
** scripts report: build/reports/scripts.log
** diffable log: build/reports/cleanlog.log
$ xdg-open build/reports/targets.png
$ _
 
== Правка ==
Например, поменяем браузер с {{pkg|firefox}} на {{pkg|chromium}}<ref>если установлен пакет {{pkg|git-core}}, можно лишний раз проверить внесённые изменения при помощи {{cmd|git diff}} (сборочный профиль постадийно коммитится при формировании)</ref>:
 
$ 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
 
Таким образом, для модификации пакетной базы можно просто добавить или убрать нужное в конфигурационном файле и списках пакетов, после чего запустить в сборочном каталоге команду {{cmd|make}} — отработав, она должна выдать ту же строчку с информацией по собранному ISO (в случае повторной сборки может понадобиться предварительно выполнить {{cmd|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 и на этом с ним закончить, используя полученный образ.
 
В случае же наличия желания поделиться наработками с коллегами — что может [http://vimeo.com/23522095 пригодиться в будущем], когда не придётся делать те же правки поверх следующей версии, ведь они уже включены — можно прислать мне (<tt>mike</tt><tt>@</tt><tt>altlinux</tt>.<tt>org</tt>) полученный патч, закоммитив изменения и прибавив описание их предназначения<ref>{{cmd|git commit}} без {{cmd|-m}} запустит текстовый редактор с тем, чтобы можно было более подробно описать суть сделанного, чем одной строкой; если ещё не дружите с {{cmd|vim}}, запишите нужное в переменную окружения <tt>EDITOR</tt></ref>:
 
$ 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'''
 
= Обобщаем в метапрофиль =
Сразу стоит сказать, что в сумме это заметно сложней. Причина не только в том, что больше файлов — а и в том, что если локальный форк является делом личным, то в случае подготовки к включению в основную ветвь разработки приходится учитывать не только свои интересы, решённые здесь и сейчас, а и долгосрочные цели других людей.
 
Например, патч с заменой {{pkg|firefox}} на {{pkg|seamonkey}} в {{path|pkg.in/lists/tagged/desktop+network}} будет идентичен вышеприведённому, но в апстрим он попадёт только в случае признания именно Seamonkey рекомендуемым браузером производства Mozilla.
 
Поэтому придётся оценивать, в каком месте и как произвести требуемое изменение.
 
Таких мест есть несколько (это наши [[Mkimage/Profiles/m-p/objects|объекты]]):
* прямое указание в <tt>*_PACKAGES</tt> для своего дистрибутива<ref>в {{pkg|mkimage-profiles}} <= 0.7.4 так можно добавить {{pkg|seamonkey}}, но не убрать добавленный списком {{pkg|firefox}}, потому что <tt>*_LISTS</tt> раскрываются позже <tt>*_PACKAGES</tt>; характерный признак — сообщение <tt>Package firefox is not installed, so not removed</tt> в {{path|build/build.log}}</ref>;
* создание и применение отдельного пакаджлиста, если добавляется взаимосвязанная группа пакетов;
* описание «технической» или собираемой дистрибутивной цели, добавляющей такой пакет или пакаджлист.
 
Пример замены {{pkg|firefox}} на {{pkg|seamonkey}} для {{pkg|mkimage-profiles}} > 0.7.4<ref>для более ранних версий придётся применить обход с созданием и подключением дополнительного списка пакетов в таком же составе</ref> — изменяется файл {{path|conf.d/live.mk}}<ref>по состоянию на 2014 год может быть больше смысла отталкиваться от {{path|conf.d/regular.mk}} в качестве исходной точки, см. [[regular|регулярные сборки]] и [[starterkits|стартовые наборы]]</ref><ref>а ещё лучше не править существующие и изменяющиеся файлы вроде {{path|regular.mk}}, но создать в {{path|conf.d/}} свой по образу и подобию, где и описывать свои производные -- это избавит от merge conflict'ов при обновлении профиля</ref>:
 
distro/live-seamonkey: distro/live-icewm
        @$(call add,LIVE_PACKAGES,firefox- seamonkey)
 
Используется синтаксис [http://www.gnu.org/software/make/manual/make.html GNU make], так что читаются эти две строчки таким образом:
* цель <tt>distro/live-seamonkey</tt> зависит от цели <tt>distro/live-icewm</tt> (то есть последняя должна быть выполнена, чтобы приступить к выполнению первой);
* «рецепт» действий содержит вызов функции <tt>add</tt> с параметрами «<tt>LIVE_PACKAGES</tt>» и «<tt>firefox- seamonkey</tt>».
 
Если при этом требуется удаление какого-либо пакета — стоит проследить, где именно при построении конфигурации дистрибутива он появляется<ref>обычно помогает {{cmd|grep}}</ref>, и обсудить в [http://lists.altlinux.org/mailman/listinfo/devel-distro devel-distro@] варианты внесения корректировки. Для взятого примера цепочка выглядит так (можно добавить при сборке <tt>REPORT=1</tt> и просмотреть полученный {{path|targets.png}}):
# <tt>distro/live-icewm</tt>
# <tt>distro/.live-desktop</tt>
# <tt>+live</tt> = <tt>use/live/desktop</tt>
# <tt>@$(call add,LIVE_LISTS,$(call tags,desktop && (live || network)))</tt>
# <tt>pkg.in/lists/tagged/desktop+network</tt>
 
При этом цель <tt>distro/.live-desktop</tt> используется как основа для всех «более-менее пользовательских» LiveCD, а цель <tt>use/live/desktop</tt> описана достаточно объёмно для того, чтобы форкать её целиком; может иметь смысл обсудить следующий вариант переработки:
 
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» в виде <tt>use/live/desktop</tt> останется неизменным, но появится возможность использовать его большую часть, но не полный блок конфигурации, поставив зависимость от <tt>use/live/.desktop</tt>.
 
Следует заметить, что одной из основных идей метапрофиля является возможность комбинирования «неопределённости в заданном направлении» (часть задачи, формулируемая примерно как «нужен livecd») и точности в том, где есть конкретные требования (например, «firefox версии 10»). Выражается это в том, что можно основываться на уже существующих образах и фичах либо построить всё почти с нуля; можно брать существующие списки пакетов, а можно жёстко задать свои. Разумный баланс (точнее, его пределы) для каждого образа могут быть свои, но как общее правило — для «любительских» проектов и семейств образов стоит смелей пользоваться наследованием, а вот «ответственные» образы может быть лучше конфигурировать с явным заданием необходимой пакетной базы (и в будущем — юнит-тестов, которые надо утащить из [[Mkimage/Profiles/Desktop|m-p-d]]).
 
= Проверка неустанавливаемых пакетов =
 
Если при сборке имеем
<source lang="text">The following packages have unmet dependencies:
  branding-school-junior-indexhtml: Depends: docs-school-junior
  udisks2: Depends: ntfsprogs
  xfce4-full: Depends: xfce4-genmon-plugin
              Depends: xfce4-wmdock-plugin
E: Broken packages</source>


Во включаемом в {{path|build/live/Makefile}} файле {{path|build/live/stage2cfg.mk}} заметно, какие переменные влияют на состав пакетной базы формирующего LiveCD субпрофиля; из них наиболее употребимы <tt>THE_PACKAGES</tt> и <tt>THE_LISTS</tt>.
См. [[Mkimage/debug#unmets]]


Заполняются эти переменные в {{path|build/distcfg.mk}}, а посмотреть окончательные значения, принятые в сборку — можно в {{path|build/build.log}} после её завершения<ref>для тестового прогона можно добавить опцию <tt>CHECK=1</tt>, см. {{path|doc/params.txt}}</ref>. Пакаджлисты трактуются как имена файлов со списками имён пакетов, расположенных ниже {{path|build/pkg/lists}}.
Обычно помогает указать оба пакета вместе. Например, вместо одного {{pkg|udisks2}} указать
udisks2
  ntfsprogs


[to be continued]
[to be continued]
= Ссылки =
* [[Mkimage/FAQ]]
* [[Branding]]
* [http://nightly.altlinux.org/docs/mkimage-profiles.html документация m-p одной книжкой]
* [http://forum.altlinux.org/index.php?topic=37282.msg298979#msg298979 доработка образа с tde] (пример из жизни)
* [http://forum.russ2.com/index.php?showtopic=3310&st=30&gopid=48142&#entry48142 про CLEANUP_PACKAGES]


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

Текущая версия от 13:59, 1 апреля 2023

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

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

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

Для сборки без установки системы на базе ALT можно задействовать сборочный стартеркит — LiveCD со всем нужным (включая настроенный hasher и установленный пакет mkimage-profiles), который можно запустить на временно свободном железе или в виртуалке с доступом в интернет (пакеты будут загружаться с публичного сервера).

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

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

Если предполагаете собирать дистрибутив на ином репозитории, нежели текущая стабильная ветка -- стоит ориентироваться на версию (по крайней мере ветку) пакета mkimage-profiles в нём; в т.ч. и при работе с mkimage-profiles.git.

Внимание! Ни в коем разе не запускайте сборку от имени root!
hasher-priv: caller has invalid uid: 0


Проверка

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

$ make live-icewm.iso

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

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

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

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

$ kvm -m 1024 -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 после её завершения[3]. Содержимое *_LISTS трактуется как имена файлов со списками имён пакетов, расположенных ниже build/pkg/lists.

При сборке с добавлением в параметры make REPORT=1 и наличии graphviz будет собрана визуализация графа зависимостей между промежуточными целями make:

$ make REPORT=1 live-icewm.iso
[...]
** target graph report: build/reports/targets.png
** scripts report: build/reports/scripts.log
** diffable log: build/reports/cleanlog.log
$ xdg-open build/reports/targets.png
$ _

Правка

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

$ 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) полученный патч, закоммитив изменения и прибавив описание их предназначения[5]:

$ 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 для своего дистрибутива[6];
  • создание и применение отдельного пакаджлиста, если добавляется взаимосвязанная группа пакетов;
  • описание «технической» или собираемой дистрибутивной цели, добавляющей такой пакет или пакаджлист.

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

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».

Если при этом требуется удаление какого-либо пакета — стоит проследить, где именно при построении конфигурации дистрибутива он появляется[10], и обсудить в 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).

Проверка неустанавливаемых пакетов

Если при сборке имеем

The following packages have unmet dependencies:
  branding-school-junior-indexhtml: Depends: docs-school-junior
  udisks2: Depends: ntfsprogs
  xfce4-full: Depends: xfce4-genmon-plugin
              Depends: xfce4-wmdock-plugin
E: Broken packages

См. Mkimage/debug#unmets

Обычно помогает указать оба пакета вместе. Например, вместо одного udisks2 указать

udisks2
ntfsprogs

[to be continued]

Ссылки

Примечания

  1. подразумевается, что мы работаем со свежей копией mkimage-profiles.git, находясь в соответствующем каталоге
  2. требует modprobe kvm_intel или modprobe kvm_amd сообразно процессору (см. тж. сервис qemu-kvm), а также группу vmusers для доступа к /dev/kvm
  3. для тестового прогона можно добавить опцию CHECK=1, см. doc/params.txt
  4. если установлен пакет git-core, можно лишний раз проверить внесённые изменения при помощи git diff (сборочный профиль постадийно коммитится при формировании)
  5. git commit без -m запустит текстовый редактор с тем, чтобы можно было более подробно описать суть сделанного, чем одной строкой; если ещё не дружите с vim, запишите нужное в переменную окружения EDITOR
  6. в mkimage-profiles <= 0.7.4 так можно добавить seamonkey, но не убрать добавленный списком firefox, потому что *_LISTS раскрываются позже *_PACKAGES; характерный признак — сообщение Package firefox is not installed, so not removed в build/build.log
  7. для более ранних версий придётся применить обход с созданием и подключением дополнительного списка пакетов в таком же составе
  8. по состоянию на 2014 год может быть больше смысла отталкиваться от conf.d/regular.mk в качестве исходной точки, см. регулярные сборки и стартовые наборы
  9. а ещё лучше не править существующие и изменяющиеся файлы вроде regular.mk, но создать в conf.d/ свой по образу и подобию, где и описывать свои производные -- это избавит от merge conflict'ов при обновлении профиля
  10. обычно помогает grep