Mkimage-profiles/design

Принятые решения по mkimage-profiles

раздельные стадии конфигурации и сборки

Быстро стало ясно, что ./configure --with-distro — это не наш путь, поскольку autoconf не даёт возможности построения конфигурации дистрибутива (см. соответствующую простыню с выставлением дефолтов нескольких значений в configure.ac m-p-d).

Поэтому:

1. инициализируем среду сборки (BUILDDIR)
2. конфигурируем дистрибутив (make в каталоге профиля, пишет в BUILDDIR)
3. конфигурируем среду сборки (./configure в BUILDDIR)
4. выполняем собственно сборку (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, а конфигурация будущего дистрибутива собирается во включаемый конфигурационный файл в корне генерируемого дистрибутивного профиля, который затем используется в процессе генерации профиля и сборки по нему дистрибутива.

Под вопросом

структура подкаталога lists/

1. плоская, как сейчас (при этом тегированные списки вынесены в подкаталог tagged/)
   • довольно просто реализуется и ничто не должно ломаться
2. иерархическая — например, 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 ) инкрементально построенный список того, что должно остаться. В школе говорили, что минус на минус даёт плюс ;-)