mkimage-profiles, или m-p — результат осмысления и обобщения опыта создания семейств дистрибутивов свободного программного обеспечения на базе ALT Linux.
Цели
Средства
Двухуровневость:
Примеры использования
Выполняем начальные инструкции по документации:
git clone git://git.altlinux.org/people/mike/packages/mkimage-profiles.git cd mkimage-profiles make rescue.iso
Brief summary
Configurables: ~/.mkimage/profiles.mk; see doc/params.txt and conf.d/README
License: GPLv2+, see COPYING
Most docs are in Russian, welcome to learn it or ask for English.
Задача:
Концепция:
Особенности:
Стадии работы:
Объекты:
дистрибутивы и виртуальные среды/машины:
субпрофили:
фичи:
списки пакетов (*_LISTS):
Результат:
при успешном завершении сборки образ называется по имени цели и укладывается в $(IMAGEDIR):
См. тж.:
doc/:
Примечание: пути в документации задаются от каталога верхнего уровня, если не указаны как относительные в явном виде (./) или по смыслу.
Удачи; что не так — пишите.
Michael Shigorin <mike@altlinux.org>
При запуске на сборку принимается ряд переменных (см. тж. profiles.mk.sample):
APTCONF
ARCH
ARCHES
AUTOCLEAN
BELL
BUILDDIR
BUILDDIR_PREFIX
BUILDLOG
CHECK
CLEAN
DEBUG
DISTRO_VERSION
HOMEPAGE, HOMENAME, HOMEWAIT
ISOHYBRID
NICE
QUIET
REPORT
ROOTPW
SAVE_PROFILE
SORTDIR
значение: пусто (по умолчанию) либо строка
SQUASHFS
значение:
STATUS
значение:
VM_SIZE
make DEBUG=1 CLEAN=1 syslinux.iso
Особенности дистрибутива, не учитываемые в пакетной базе или зависящие от переменных времени сборки/установки образа; по необходимости влияют на конфигурацию, приносят с собой или запрашивают скрипты, которые могут быть оформлены как:
В большинстве случаев можно рекомендовать создание feature средствами метапрофиля, поскольку при этом дерево кода более удобно для анализа и обновления (и в отличие от m-p-d — нет вынужденной необходимости либо контролировать включение нужных фич "вручную" в скриптах по косвенным признакам, либо выносить их в пакеты installer-feature-*); также возможно добиться большей степени интеграции по данным (например, язык gfxboot и LiveCD).
Создание и упаковку installer-feature-* можно рекомендовать, если:
Стоит избегать изменения пакетных умолчаний в случае, когда их представляется осмысленным и возможным скорректировать в пакете: таким образом они станут более дистрибутивными.
Обратите внимание, что фичи включаются в комплект инкрементально: что добавили, то уже не убрать; поэтому при необходимости следует выделять промежуточные цели сборки, собирающие необходимые фичи и оставляющие те, по которым есть расхождения, на включение ближе к конечной дистрибутивной цели.
Соглашение по именованию таково, что цели use/ФИЧА и use/ФИЧА/… определяются в файле features.in/ФИЧА/config.mk и только в нём.
Состав пакетной базы субпрофилей определяется значениями следующих переменных профиля (см. тж. conf.d/README):
main: пакетная база для установки
THE_KMODULES, BASE_KMODULES, MAIN_KMODULES, BASE_KMODULES_REGEXP
stage2: общая часть install2, live, rescue
STAGE1_KMODULES, STAGE1_KMODULES_REGEXP, STAGE2_KMODULES, STAGE2_KMODULES_REGEXP
install2: компактная "живая" система, содержащая только инсталятор
см. stage2
live: пользовательский LiveCD (может содержать также инсталятор)
rescue: спасательный LiveCD
stage1: ядро и загрузчик второй стадии
STAGE1_KMODULES_REGEXP
Этот каталог содержит включаемые фрагменты конфигурации образов с тем, чтобы было удобнее параллельно разрабатывать специфические образы без излишних merge conflict'ов.
Следует понимать, что основная цель появления mkimage-profiles на свет — это уменьшение "форков" внутри семейства дистрибутивных профилей. Поэтому при возможности следует всё-таки работать над общей базовой частью, включая скриптовые хуки и списки пакетов, а также оптимизировать граф зависимостей между конфигурациями образов.
Попросту говоря, copy-paste — тревожный признак.
Вместо него нередко может помочь выделение кусочков конфигурации в пределах включаемого файла в цели mixin/*, которые не являются самостоятельными или даже промежуточными, но включают полезные группы настроек, нужных в различных образах, не наследующих друг другу — посмотрите существующие примеры использования.
По переменным (см. тж. doc/pkglists.txt):
для направленного действия служат:
аналогично по kernel-modules-*:
Не стоит бояться такого разнообразия, для большинства задач достаточно THE_*.
По подстановкам:
По спискам пакетов:
Этот каталог копируется из метапрофиля в профиль "как есть" и формирует "заготовку" финальной стадии, собирающей собственно образ из результатов работы индивидуальных субпрофилей (для distro) либо непосредственно "на месте" (для ve, vm).
Содержимое image.in/files/ копируется в корень образа.
Соответственно для сборки также потребуется одна из фич features.in/build-*.
Пакетная база рабочего чрута минимальна (может чуть расширяться фичами — см. features.in/repo/lib/50-genbasedir.mk в качестве примера).
Если требуется какая-либо иная обработка чрута, следует предпочитать scripts.d — для универсальной обработки скрипт можно добавить здесь, для специфичной — в фичу.
Результат — готовый образ в $(IMAGEDIR)/.
Этот каталог содержит т.н. фичи (features, особенности).
Фича — отдельно подключаемая сущность, которая содержит повторно используемые конфигурацию/код и определяет одну из особенностей создаваемого образа. Может зависеть от других фич либо субпрофилей.
Каждая фича должна содержать файл config.mk, включаемый в main.mk при построении конфигурации будущего профиля; он может описывать одну или более целей вида use/*, дополняющих конфигурацию, и обязан добавить имя фичи в $(FEATURES), для чего создана функция add_feature.
На этапе генерации сборочного профиля фичи рассматриваются после инициализации профиля (см. image.in/) и копирования субпрофилей (см. sub.in/). Для каждой фичи, указанной в $(FEATURES), копируются подкаталоги сообразно включенным субпрофилям, а также lib/ и {image-,}scripts.d/; затем выполняются generate.sh и generate.mk при их наличии.
Если фича дополняет хуками семейство целевых субпрофилей, построенных на одном базовом, можно воспользоваться подкаталогом с именем исходного базового субпрофиля (см. $src, $dst в Makefile).
Рекомендуется давать несколько различающиеся имена скриптам, которые одна и та же фича может добавлять в различные стадии, чтобы они не выглядели одинаково в логе сборки.
Наиболее востребованные цели можно снабжать "ярлычками" вроде "+icewm" с тем, чтобы сделать более краткими и выразительными использующие их правила. Просьба не злоупотреблять количеством, такие имена предполагается показывать в интерфейсе к профилю.
Каталог lib/ является специфическим для фич, определяющих построение конкретного вида образа — см. build-*/.
Несложный пример содержится в 00example/, более близкий к жизни и нынешним пределам возможностей метапрофиля — в syslinux/.
См. тж. файлы README в каталогах фич (отсутствие — баг!).
Этот каталог содержит субпрофили; содержимое затребованных (названия которых содержатся в значении переменной SUBPROFILES, которую заполняют цели sub/* — см. lib/sugar.mk) будет скопировано в корневой каталог формируемого профиля.
Просьба ответственно относиться к изменению существующих субпрофилей и вдумчиво — к созданию новых; возможно, достаточно всего лишь оформить нужное новой фичей (см. features.in/).
Обратите внимание: поскольку сборка частей дистрибутивного образа и происходит в каталогах субпрофилей, то повторное использование одного простого субпрофиля в рамках сгенерированного профиля штатным образом невозможно. Если требуется создать несколько близких по реализации субпрофилей, изучите stage2 и задействующие его фичи.
Краткое описание существующих вариантов (см. соотв. README):
Этот каталог содержит субпрофиль main, собирающий пакетную базу для локальной инсталяции дистрибутива из полученного образа, включая необязательные пакеты; в distro/live-builder применяется как локальный репозиторий для сборки.
Рекомендуется использовать BASE_PACKAGES и BASE_LISTS для того, что должно быть установлено по умолчанию, и MAIN_PACKAGES, MAIN_LISTS — для того, что должно быть доступно на носителе; подробнее см. в документации фичи metadata.
Если что-либо требуется как в main, так и в live, применяйте THE_PACKAGES и THE_LISTS вместо дублирования вручную.
В image-scripts.d смысла нет, только scripts.d, т.к. рабочий чрут не содержит исполняемых файлов.
Не следует использовать этот субпрофиль напрямую, для добавления пакетного репозитория в образ предназначена фича use/repo/main.
Результат — каталог ALTLinux/RPMS.main для копирования в образ (если не указан иной суффикс посредством переменной MAIN_SUFFIX).
Этот каталог содержит субпрофиль первой стадии загрузки; здесь место syslinux (загрузчик) и propagator (ориентировка на местности, вытягивание второй стадии с CD/FTP/…).
Скрипты запускаются извне формируемого образа (scripts.d/); следует крайне бережно относиться к объёму этой стадии.
Обратите внимание: если не указать явно требуемый вариант ядра посредством STAGE1_KFLAVOUR, будет взят последний из перечисленных в KFLAVOURS; если не указать явно регэкс, описывающий требуемые в инсталяторе kernel-modules-*, посредством STAGE1_KMODULES_REGEXP — будут доступны модули из kernel-image (упаковываются в syslinux/alt0/full.cz).
Требуется для инсталяционных, live- и rescue-образов, соответствующими фичами подключается автоматически (в силу зависимости stage2 от stage1).
Результат — каталог syslinux/ для копирования в образ.
Этот каталог содержит общий базовый субпрофиль "живой" второй стадии, используемый для сборки образов install2, live, rescue (возможно, нескольких одновременно в составе одного дистрибутива).
Зависимость на него стоит прописывать в таких фичах; сама по себе (без нужного stage2cfg.mk) смысла не имеет.
Обратите внимание, что набор потенциально доступных в stage1 модулей ядра для stage2 может быть расширен (STAGE2_KMODULES).
Результат — соответственно названный файл со squashfs, подлежащий копированию в итоговый образ.
NB: смонтированный образ доступен в такой системе как /image/.
Этот каталог содержит все возможные списки пакетов и описания групп, которые по мере необходимости копируются из метапрофиля в формируемый профиль.
Этот каталог содержит списки пакетов, копируемые из метапрофиля в создаваемый профиль по необходимости (определяется по наличию имён списков в переменных *_LISTS, см. реализацию в ./Makefile).
Список .base является особенным (формирует базовую систему, см. http://www.altlinux.org/Alterator-pkg); он создаётся из содержимого ряда переменных (см. реализацию).
Подкаталог tagged содержит тегированные списки, имена которых удобно получать функцией tags() (см. lib/functions.mk).
Для выявления дубликатов в составе списков служит ‘make pkgdups’; пытаться избежать дублей на 100% скорее бесполезно, но бродячие устойчивые группы пакетов могут заслуживать выделения отдельным списком.
При копировании списков в BUILDROOT происходит их обработка с применением архитектурнозависимых макросов, см. doc/archdep.txt
NB: списки пакетов есть смысл выделять в файлы при повторном использовании либо при заметном объёме, когда перечисление прямо в конфигурации сильно снижает её читаемость.
Этот каталог содержит тегированные списки; на данный момент реализация (bin/tags2lists) требует, чтобы каждый из тегов был отдельным словом из символов в наборе [a-zA-Z0-9_]
Не используйте в слове "-"); рекомендуется разделять слова "+".
Применение: дополнение жёстко статически заданной функциональности (как правило, обязательной в данном образе) более "плавающим" в долгосрочном плане результатом раскрытия списка тегов (который может покрывать второстепенные вещи способом, обычно требующим меньше внимания).
Реализация никак не сопряжена с pkg.in/groups/
Этот каталог содержит описания групп, копируемые из метапрофиля в создаваемый профиль по необходимости (только фигурирующие в списке, которым является значение переменной MAIN_GROUPS).
В данный момент перенесено почти 1:1 из mkimage-profiles-desktop, требует увязки с pkg.in/lists/tagged/
Некоторые фрагменты кода закладываются на определённое поведение других частей mkimage-profiles либо содержание переменных.
NB: пути приводятся от верхнего уровня; проект в целом предполагает наличие ALT 8.0+ и GNU make 3.82+ (на которых и разрабатывается), но может быть портирован вместе с mkimage. Если что-либо не работает или не собирается, стоит проверить на Sisyphus (mkimage, make, hasher, собственно пакетная база), поскольку именно на нём происходит основная разработка mkimage-profiles. Сломанная сборка на текущем стабильном бранче считается ошибкой и подлежит исправлению, если оно технически возможно на базе этого бранча.
lib/report.mk
pkg.in/lists/Makefile
характерное сообщение об ошибке:
E: Couldn't find package
sub.in/stage1/Makefile
features.in/syslinux/scripts.d/20-propagator-ramdisk
image.in/Makefile
При отладке сборки конфигурации или самого дистрибутива могут оказаться полезными следующие средства:
build/distcfg.mk
build/build.log
REPORT=1 включает генерацию дополнительного вывода:
Общая информация по отладке сборки профилей mkimage доступна на вики: http://www.altlinux.org/Mkimage/debug
ВНИМАНИЕ: заключительная операция создания образа жёсткого диска из архива с содержимым корневой файловой системы требует доступа к sudo и разрешения на выполнение скрипта bin/tar2fs в корневом каталоге метапрофиля при установке mkimage-profiles из пакета (это в планах исправить, но подход к libguestfs пока успехом не увенчался).
Соответствующий фрагмент конфигурации sudo(8) может выглядеть как:
mike ALL=NOPASSWD: /usr/share/mkimage-profiles/bin/tar2fs
При работе с локальной копией mkimage-profiles.git следует иметь в виду, что предоставлять недоверенному пользователю право выполнять от имени root доступный ему по записи скрипт равнозначно предоставлению полных привилегий root (поэтому фича build-vm сперва проверяет наличие системно установленного пакета и по возможности старается запустить под sudo скрипт из него, доступный по записи только root).
Для работы с более специфичными форматами, чем raw ("буквальный" образ диска), потребуется утилита qemu-img из одноименного пакета; см. тж. вывод команды make help/vm
Также потребуется пакет multipath-tools (/sbin/kpartx).
Пример сборки и запуска VM:
$ make ROOTPW=reallysecret1 vm/bare.img && kvm -hda ~/out/bare.img
Если при сборке образа файловой системы произойдёт сбой, может оказаться нужным вручную освободить используемые loop-устройства, например, так:
# losetup -a # kpartx -d /dev/loop0 # losetup -d /dev/loop0
Для сборки на "неродной" архитектуре с применением трансляции посредством QEMU установите пакет livecd-qemu-arch и выполните команду register-qemu-armh от имени root (также предоставляется register-qemu-ppc, но как минимум при сборке под ppc32 на x86_64 известны проблемы эмуляции).
Пример запуска:
make ARCH=armh APTCONF=/etc/apt/apt.conf.sisyphus.arm ve/bare.tar
Обратите также внимание на http://bugzilla.altlinux.org/34638
Достаточно воспользоваться ifeq/ifneq, сравнивая $(ARCH) с нужным:
ifeq (x86_64,$(ARCH)) EFI_LISTS := $(call tags,base efi) endif
При необходимости сравнить со списком ("любой x86") можно сделать так:
ifeq (,$(filter-out i586 x86_64,$(ARCH))) use/x11/xorg: use/x11 use/x11/intel use/firmware else use/x11/xorg: use/x11 endif
В рецептах (shell-часть Makefile) используйте $(ARCH) или $$ARCH.
Бывает так, что в списке пакетов есть смысл упоминать какой-либо из них только для определённой архитектуры (например, wine или steam); в таких случаях можно воспользоваться механизмом подстановки, который пословно обрабатывает списки и в случае наличия суффикса @ARCH оставляет только слова, в которых этот суффикс соответствует заданной архитектуре сборки.
Например, для Simply Linux в mkimage-profiles-desktop есть строчки:
@I586_ONLY@haspd @X86_64_ONLY@i586-haspd
В случае mkimage-profiles они должны выглядеть так:
haspd@i586 i586-haspd@x86_64
или упрощённо (с версии 1.2.12):
haspd@IA32
Для преобразования можно воспользоваться следующей командой:
sed -r -e 's/@I586_ONLY@([^\t ]+)/\1@i586/g' \ -e 's/@X86_64_ONLY@([^\t ]+)/\1@x86_64/g'
При необходимости добавить пакет только на x86-архитектурах (неважно, i586 или x86_64) можно воспользоваться макросом X86 (с версии 1.2.12):
xorg-drv-intel@X86
Аналогичная функциональность реализована для профилей установки.