Mkimage-profiles/design
Принятые решения по mkimage-profiles
раздельные стадии конфигурации и сборки
Быстро стало ясно, что ./configure --with-distro — это не наш путь, поскольку autoconf не даёт возможности построения конфигурации дистрибутива (см. соответствующую простыню с выставлением дефолтов нескольких значений в configure.ac m-p-d).
Поэтому:
- инициализируем среду сборки (BUILDDIR)
- конфигурируем дистрибутив (make в каталоге профиля, пишет в BUILDDIR)
- конфигурируем среду сборки (./configure в BUILDDIR)
- выполняем собственно сборку (make в BUILDDIR)
ARCH, APTCONF, MKIMAGE_PREFIX (см. doc/variables.txt) можно передать в командной строке либо рутинно через ~/.mkimage/profiles.mk.
r/o git
Сборка происходит вне собственно метапрофиля (максимум модификации — симлинк в сборочный каталог, если каталог метапрофиля доступен на запись). Этим достигается дистрибутивность дистрибутивного профиля (возможна сборка прямо из /usr/share, например, в live-builder.iso) и одновременно в корне снимается риск коммитов сборочного мусора (подставленные .in-файлы и т. п.).
Схема: метапрофиль => профиль => образ
Порождённые профили являются полностью самостоятельными.
формирование списков для субпрофилей
Создаётся единый конфигурационный makefile (distcfg.mk в корне сборочного каталога), в который при конфигурировании дистрибутива добавляются пары переменная-значение. При этом возможно использование немедленных и отложенных подстановок переменных и до сих пор получилось избежать необходимости макроподстановок при помощи autoconf.
В сборочный каталог копируются только необходимые (перечисленные в переменных *_LISTS) пакаджлисты. Субпрофили различаются по префиксам имён переменных, в которые укладываются относящиеся к ним сущности: INSTALL2_PACKAGES, BASE_LISTS… в одном toplevel distcfg.mk.
Списки тегов превращаются в списки пакаджлистов до передачи в BUILDDIR.
субпрофили и пакаджлисты в сборочном каталоге
Из метапрофиля в профиль попадают только нужные каталоги субпрофилей/фич и только нужные пакаджлисты — с тем, чтобы избежать возможности неявного использования объектов из «грязной» среды (ср. со сборкой пакета в хост-системе или в hasher chroot).
phony targets
Сейчас сделан выбор стиля «все цели являются липовыми», то есть им не соответствуют существующие или создаваемые каталоги/файлы. Обоснование: когда неочевидно, что какой-либо цели соответствует объект ФС, отладка может затрудниться тем, что make не будет пересоздавать такой объект, если не обновлялись его prerequisites (которые обычно оказываются phony). При этом цена вопроса безусловного пересоздания любой цели на этапе конфигурирования пренебрежимо мала — максимум единицы секунд.
Когда-то в будущем может возыметь смысл переработка mkimage и mkimage-profiles с использованием честных файловых зависимостей и более тесной интеграцией, но это вне рамок данного проекта.
propagator+syslinux = stage1
Каждый субпрофиль создаётся, конфигурируется и применяется в явном виде. Так, создан субпрофиль stage1 (аналогично install2 и всем им соответствуют подкаталоги sub.in/*/), куда перенесена подготовка propagator и syslinux; в корне собираемого профиля — только сборка образа (сейчас — также Metadata, .disk/* и индексов репозиториев), см. image.in/Makefile.
make+shell vs autoconf
Выбор сделан в пользу инициализации небольшого количества дефолтов перед сборкой конфигурации и возможности добавления локального profiles.mk в самом её конце (отчасти уже давно, но финализировано после детального обсуждения с Алексеем Чеусовым).
При этом основополагающая информация (BUILDDIR) передаётся через переменные make, а конфигурация будущего дистрибутива собирается во включаемый конфигурационный файл в корне генерируемого дистрибутивного профиля, который затем используется в процессе генерации профиля и сборки по нему дистрибутива.
этажность
Начиная с 0.5.3, m-p стали не двух-, а трёхэтажными: добавился слой разбора аргументов верхнего уровня, отвечающий за сборку нескольких образов под несколько архитектур сразу. Точнее, он оккупировал Makefile верхнего уровня, а прежнее содержимое переехало в main.mk рядом.
Это же оказалось полезным для «гипервизора» (REPORTS=1), создающего отчёты по итогам выполнения стадий сборки конфигурации и образа.
Под вопросом
структура подкаталога lists/
- плоская, как сейчас (при этом тегированные списки вынесены в подкаталог tagged/)
- довольно просто реализуется и ничто не должно ломаться
- иерархическая — например, base/server
- должно быть более масштабируемым даже при переходе многих пакаджлистов на теги
взаимодействие тегированных списков и pkg/groups
Пока совсем неясно, потребуется рассмотрение активными пользователями alterator-pkg.
тегированные скрипты
Была сделана первичная реализация (см. features.in/Makefile), поддерживавшая выборку скриптов из features.in/$feat/tagged/{image-,}scripts.d/ по набору тегов, который состоял из названия фичи (например, cleanup) и названия/названий стадии (например, install2 || stage2).
- внятный и удобный механизм конструирования полезных запросов пока не придуман
- похоже, есть смысл сделать переменные-коллекторы, в которые автоматически попадают списки имён, производные от конфигурации дистрибутива или его частей (частичный пример см. в виде dirtags в features.in/Makefile)
- не взлетело, получилось слишком хрупким и малоюзабельным
зачистка
Крайне неприятная тема: профиль нацелен на инкрементальное построение, а зачистка идёт против этого принципа (даже если строить её саму инкрементально). Бродят разные мысли:
- списки вроде KEEP_PATHS, KEEP_PACKAGES с тем, чтобы проверять их значения и не удалять указанное в cleanup-скриптах;
- изначально брать полный набор cleanup'ов для заданных стадий, но вычитать из них (тегами или на крайний случай tags2lists ) инкрементально построенный список того, что должно остаться. В школе говорили, что минус на минус даёт плюс ;-)
зависимые фичи
Например, use/vm/kvm/guest имеет смысл только с use/x11/xorg, но хорошо бы, чтоб если иксов ещё нет — то они и не добавлялись (пока оставил «зависимость в уме»); другой вид взаимодействия («конфликт») — в случае use/cleanup и (на сегодня не выделенной явно) use/live/install: если требуется устанавливать этот же образ, то не следует заведомо нарушать его пакетную целостность.