Mkimage-profiles/oldpage
mkimage-profiles.git
К 2010 году с mkimage-profiles-desktop накопились следующие проблемы:
- очень объёмный и сложный профиль, освоение требует значительных сил и времени;
- вследствие недокументированности и отсутствия ясно изложенных и обоснованных предпочтений и практик — смешение стилей;
- перерос возможности рефакторинга — изменения либо ломают большую часть описанных дистрибутивов, либо требуют неоправданного объёма работ по выяснению и исправлению последствий.
Поэтому решил попытаться нарисовать новый профиль, который бы также позволял собирать различные десктопные и серверные iso/flash-образы, но и учитывал бы обнаруженные проблемы (в том числе более полно соответствовал изначальной задумке).
Получившийся по факту метапрофиль (репозиторий запчастей для построения дистрибутивов) опубликован. Просьба не воспринимать историю как постоянную — первые десятки коммитов делались как технические и предполагалась зачистка всех этих метаний по достижении некоторой точки.
Цели
- наследственность и для дистрибутивов, а не только использование общих блоков (могущих наследовать друг другу)
- прозрачность и диагностируемость формирования конфигурации
- документированность: изначальная и каждого существенного изменения
Принятые решения
раздельные стадии конфигурации и сборки
Быстро стало ясно, что ./configure --with-distro — это не наш путь, поскольку autoconf не даёт возможности построения конфигурации дистрибутива (см. соответствующую простыню с выставлением дефолтов нескольких значений в configure.ac m-p-d).
Поэтому:
- инициализируем среду сборки (BUILDDIR)
- конфигурируем дистрибутив (make в каталоге профиля, пишет в BUILDDIR)
- конфигурируем среду сборки (./configure в BUILDDIR)
- выполняем собственно сборку (make в BUILDDIR)
r/o git
Сборка происходит вне собственно метапрофиля (максимум модификации — симлинк в сборочный каталог, если каталог метапрофиля доступен на запись). Этим достигается дистрибутивность дистрибутивного профиля (возможна сборка прямо из /usr/share) и одновременно в корне снимается риск коммитов сборочного мусора (подставленные .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/
- плоская, как сейчас (при этом тегированные списки вынесены в подкаталог 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 ) инкрементально построенный список того, что должно остаться. В школе говорили, что минус на минус даёт плюс ;-)
Пожелания к коллегам
строгое обращение с потоками данных
Желательно направление движения значений переменных и действий короткими шагами «сверху вниз» — без выдёргивания значений из соседних каталогов или путешествий сверху в самый низ различным образом).
Построение списков пакетов «на лету» обдумывается, но не подобными хаками, а скорее такими (см. создание .base; также реализована выборка пакаджлистов по произвольным булевым выражениям, включающим теги).
унификация
Крайне желательно неразведение зоопарка аналогов (например, методов макроподстановки). Если вводятся новые практики или концепции, лучше предварительно обсудить задумку или реализацию в своём бранче next до того, как на новосделанное будет завязано много ценного. Если возникают конфликты мнений — давайте постараемся их разрешать, а не форкаться без планов на мерж.
повторное использование вместо дублирования
Если совсем какая-то специфика, но может пригодиться и другим (косясь на mithraen@ и asterisk-1.6.[012] в m-p-d) — может иметь смысл завести «свой» namespace для списков/фич.
построение вместо урезания
При возможности следует выбирать подход «построить из нужного», чем «добавить всякое и выбросить ненужное»: он гораздо лучше ложится на идею mkimage-profiles (создание из кусочков и минимизация непрозрачных хаков). Это позволяет надеяться на трассируемость процесса построения дистрибутива.
Вынужденным исключением на сейчас являются:
- фича install2 с зачисткой излишних модулей ядра и файлов в компактном livecd-корне инсталятора;
- фича cleanup, подготавливающая постинсталяционную зачистку лишних пакетов в свежеустановленной системе.
Объекты
дистрибутив
Цель вида distro/%, выполнение которой приводит к созданию конфигурации соответствующего дистрибутива, достаточной для построения его образа. Описываются в distro.mk; могут наследовать друг другу. Пример — distro/server-ovz.
субпрофиль
Цель вида sub/%, выполнение которой приводит к созданию базовой конфигурации соответствующего цельного блока для укладки в образ (например, sub/install2). Описаны в libdistro.mk в общем виде, размещаются в sub.in/.
Обратите внимание: sub/stage2 является базовым, а не самостоятельным, и используется посредством use/stage2/* для получения итоговых субпрофилей install2, live, rescue. sub/stage2/* являются техническими, не следует ставить их в зависимости дистрибутивов.
фича
Цель вида use/%, снабжённая подкаталогом в features.in/. В подкаталоге может быть:
- кусочек конфигурации в виде config.mk, автоматически включаемый в distro.mk;
- подкаталоги по имени нужных субпрофилей, содержимое которых добавляется к содержимому включённых в дистрибутив субпрофилей;
- подкаталоги image-scripts.d/ и scripts.d/, скрипты из которых добавляются в toplevel-каталог сборки (см. пример в features.in/syslinux/scripts.d/);
- generate.sh и/или generate.mk для постобработки;
- включаемый в сборочный каталог lib/ для фич, определяющих сборку образа (build-*).
В экспериментальном порядке рядом со *scripts.d/ обрабатываются tagged/{image-,}scripts.d/*, см. в качестве примера features.in/cleanup/tagged/image-scripts.d/01+install2+cleanup.
пакаджлист
Файл со списком пакетов, размещённый в pkg.in/lists/. Упоминается в генерируемом файле конфигурации дистрибутива (distcfg.mk) в переменных %_LISTS; перечисленные списки копируются в создаваемый профиль дистрибутива на стадии порождения дистрибутивного профиля.
Может быть тегированным (tagged/) — см. functions.mk::tags(), bin/tags2lists, features.in/rescue/config.mk по реализации и применению.
Состояние
На начало осени 2011 реализован метапрофиль, при помощи которого можно собрать несколько минималистичных дистрибутивов — по командам make server-ovz.iso или make icewm.iso собирается устанавливающийся инсталлер, из которого получается загружающаяся система, а make live.iso и make rescue.iso соберут небольшую «живую» и спасательную систему, соответственно. Заодно получается более-меее аккуратно сформированный git-репозиторий, содержащий дистрибутивный профиль по принципу --as-needed.
Сделаны и применяются тегированные пакаджлисты и скриптовые хуки (с выборкой по произвольным булевым выражениям).
Практически не втянуты pkg.in/groups/.
ARCH, APTCONF, MKIMAGE_PREFIX можно передать через ~/.mkimage/profiles.mk (autoconf вместе с ./configure исключён как класс по причине невостребованности).
Спешки по части расширения ассортимента дистрибутива нет никакой, потихоньку делается база для комфортной работы релиз-менеджеров.
Ссылки
- презентация и статья nvidia, использующих perforce+makepp в качестве средств configuration management
- Makefile::Graphviz и gvmake — визуализация зависимостей в makefiles