mkimage-profiles, или m-p — результат осмысления и обобщения опыта создания семейств дистрибутивов свободного программного обеспечения на базе ALT Linux.
Цели
Средства
Двухуровневость: метапрофиль более объёмен и сложен, но выгоден для долгосрочной разработки сгенерированный дистрибутивный профиль более легко обозрим и модифицируем как одноразовый форк наследственность на уровне индивидуальных особенностей и образов в целом прозрачность и диагностируемость формирования конфигурации документированность
Примеры использования
Выполняем начальные инструкции по документации
git clone git://git.altlinux.org/people/mike/packages/mkimage-profiles.git cd mkimage-profiles make icewm.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
BELL
BUILDDIR
BUILDDIR_PREFIX
BUILDLOG
CHECK
CLEAN
DEBUG
HOMEPAGE, HOMENAME, HOMEWAIT
ISOHYBRID
NICE
REPORT
ROOTPW
SAVE_PROFILE
SORTDIR
значение: пусто (по умолчанию) либо строка
SQUASHFS
значение:
STATUS
значение:
VM_SIZE
make DEBUG=1 CLEAN=1 syslinux.iso
Особенности дистрибутива, не учитываемые в пакетной базе или зависящие от переменных времени сборки/установки образа; по необходимости влияют на конфигурацию, приносят с собой или запрашивают скрипты, которые могут быть оформлены как:
В большинстве случаев можно рекомендовать создание feature средствами метапрофиля, поскольку при этом дерево кода более удобно для анализа и обновления (и в отличие от m-p-d — нет вынужденной необходимости либо контролировать включение нужных фич "вручную" в скриптах по косвенным признакам, либо выносить их в пакеты installer-feature-*).
Создание и упаковку installer-feature-* можно рекомендовать, если:
Стоит избегать изменения пакетных умолчаний в случае, когда их представляется осмысленным и возможным скорректировать в пакете: таким образом они станут более дистрибутивными.
Обратите внимание, что фичи включаются в комплект инкрементально: что добавили, то уже не убрать; поэтому при необходимости следует выделять промежуточные цели сборки, собирающие необходимые фичи и оставляющие те, по которым есть расхождения, на включение ближе к конечной дистрибутивной цели.
Соглашение по именованию таково, что цели use/ФИЧА и use/ФИЧА/… определяются в файле features.in/ФИЧА/config.mk и только в нём.
Состав пакетной базы субпрофилей определяется значенями следующих переменных профиля (см. тж. ../conf.d/README; некоторые "*" ниже заэкранированы ради парсера asciidoc):
main: пакетная база для установки
THE_KMODULES, BASE_KMODULES, MAIN_KMODULES, BASE_KMODULES_REGEXP
stage2: общая часть installer, live, rescue
STAGE1_KMODULES, STAGE1_KMODULES_REGEXP, STAGE2_KMODULES, STAGE2_KMODULES_REGEXP
installer: компактная "живая" система, содержащая только инсталятор
см. stage2
live: пользовательский LiveCD (может содержать также инсталятор)
rescue: спасательный LiveCD
stage1: ядро и загрузчик второй стадии
STAGE1_KMODULES_REGEXP
Этот каталог содержит включаемые фрагменты конфигурации образов с тем, чтобы было удобнее параллельно разрабатывать специфические образы без излишних merge conflict'ов.
Следует понимать, что основная цель появления mkimage-profiles на свет — это уменьшение "форков" внутри семейства дистрибутивных профилей. Поэтому при возможности следует всё-таки работать над общей базовой частью, включая скриптовые хуки и списки пакетов, а также оптимизировать граф зависимостей между конфигурациями образов.
Попросту говоря, copy-paste — тревожный признак.
По переменным (см. тж. ../doc/pkglists.txt):
для направленного действия служат:
аналогично по модулям ядра:
Не стоит бояться такого разнообразия, для большинства задач достаточно THE_*.
По подстановкам:
По спискам пакетов:
Этот каталог копируется из метапрофиля в профиль "как есть" и формирует "заготовку" финальной стадии, собирающей собственно образ из результатов работы индивидуальных субпрофилей (для distro) либо непосредственно "на месте" (для ve, vm).
Содержимое 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/distro.mk) будет скопировано в корневой каталог формируемого профиля.
Просьба ответственно относиться к изменению существующих субпрофилей и вдумчиво — к созданию новых; возможно, достаточно всего лишь оформить нужное новой фичей (см. ../features.in/).
Обратите внимание: поскольку сборка частей дистрибутивного образа и происходит в каталогах субпрофилей, то повторное использование одного простого субпрофиля в рамках сгенерированного профиля штатным образом невозможно. Если требуется создать несколько близких по реализации субпрофилей, изучите stage2 и задействующие его фичи.
Краткое описание существующих вариантов:
Шаблонное правило сейчас определено в ../lib/distro.mk, поскольку субпрофили востребованы только дистрибутивами.
Этот каталог содержит субпрофиль main, собирающий пакетную базу для локальной инсталяции дистрибутива из полученного образа, включая необязательные пакеты; в distro/live-builder применяется как локальный репозиторий для сборки.
Подбирает:
В image-scripts.d смысла нет, только scripts.d, т.к. рабочий чрут не содержит исполняемых файлов.
Не следует использовать этот субпрофиль напрямую, для добавления пакетного репозитория в образ предназначена фича use/repo/main.
Результат — каталог ALTLinux/RPMS.main для копирования в образ.
Этот каталог содержит субпрофиль первой стадии загрузки; здесь место syslinux (загрузчик) и propagator (ориентировка на местности, вытягивание второй стадии с CD/FTP/…).
Скрипты запускаются извне формируемого образа (scripts.d/); следует крайне бережно относиться к объёму этой стадии.
Обратите внимание: если не указать явно требуемый вариант ядра посредством STAGE1_KFLAVOUR, будет взят последний из перечисленных в KFLAVOURS; если не указать явно регэкс, описывающий требуемые в инсталяторе модули, посредством 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); он создаётся из содержимого ряда переменных (см. Makefile).
Подкаталог tagged/ содержит тегированные списки, имена которых удобно получать функцией tags() (см. ../../lib/functions.mk).
Для выявления дубликатов в составе списков служит ‘make pkgdups’; пытаться избежать дублей на 100% скорее бесполезно, но бродячие устойчивые группы пакетов могут заслуживать выделения отдельным списком.
Этот каталог содержит тегированные списки; на данный момент реализация (../../../bin/tags2lists) требует, чтобы каждый из тегов был отдельным словом, состоящим из символов из набора [a-zA-Z0-9_] (внимание: не используйте в слове "-"); рекомендуется разделять слова "+".
Применение: дополнение жёстко статически заданной функциональности более "плавающим" в долгосрочном плане результатом раскрытия списка тегов.
Реализация является экспериментальной и требует утряски с ../groups/; комментарии и помощь всячески приветствуются.
Этот каталог содержит описания групп, копируемые из метапрофиля в создаваемый профиль по необходимости (только фигурирующие в списке, которым является значение переменной MAIN_GROUPS).
В данный момент перенесено почти 1:1 из mkimage-profiles-desktop, требует увязки с ../lists/tagged/.
Некоторые фрагменты кода закладываются на определённое поведение других частей mkimage-profiles либо содержание переменных.
NB: пути приводятся от верхнего уровня; проект в целом предполагает ALT Linux 6.0+ и GNU make 3.81+ (на которых и разрабатывается), но может быть портирован вместе с 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/tar2vm в корневом каталоге метапрофиля при установке mkimage-profiles из пакета (это в планах исправить, но подход к libguestfs пока успехом не увенчался).
Соответствующий фрагмент конфигурации sudo(8) может выглядеть как:
mike ALL=NOPASSWD: /usr/share/mkimage-profiles/bin/tar2vm
При работе с локальной копией mkimage-profiles.git следует иметь в виду, что предоставлять недоверенному пользователю право выполнять от имени root доступный ему по записи скрипт равнозначно предоставлению полных привилегий root.
Для работы с более специфичными форматами, чем raw ("буквальный" образ диска), потребуется утилита qemu-img из одноименного пакета; см. тж. вывод команды make help/vm
Также потребуется пакет multipath-tools (/sbin/kpartx).
Пример сборки и запуска VM:
$ make ROOTPW=reallysecret1 vm/bare.img && kvm -hda ~/out/bare.img
Для сборки на "неродной" архитектуре с применением трансляции посредством QEMU установите пакет livecd-qemu-arch и выполните команду register-qemu-arm от имени root (также предоставляется register-qemu-ppc, но как минимум при сборке под ppc32 на x86_64 известны проблемы эмуляции).
Пример запуска:
make ARCH=arm APTCONF=/etc/apt/apt.conf.sisyphus.arm ve/bare.tar