Mkimage-profiles/oldpage

Материал из ALT Linux Wiki


mkimage-profiles.git

К 2010 году с mkimage-profiles-desktop накопились следующие проблемы:

  • очень объёмный и сложный профиль, освоение требует значительных сил и времени;
  • вследствие недокументированности и отсутствия ясно изложенных и обоснованных предпочтений и практик — смешение стилей;
  • перерос возможности рефакторинга — изменения либо ломают большую часть описанных дистрибутивов, либо требуют неоправданного объёма работ по выяснению и исправлению последствий.

Поэтому решил попытаться нарисовать новый профиль, который бы также позволял собирать различные десктопные и серверные iso/flash-образы, но и учитывал бы обнаруженные проблемы (в том числе более полно соответствовал изначальной задумке).

Получившийся по факту метапрофиль (репозиторий запчастей для построения дистрибутивов) опубликован. Просьба не воспринимать историю как постоянную — первые десятки коммитов делались как технические и предполагалась зачистка всех этих метаний по достижении некоторой точки.

Цели

  • наследственность и для дистрибутивов, а не только использование общих блоков (могущих наследовать друг другу)
  • прозрачность и диагностируемость формирования конфигурации
  • документированность: изначальная и каждого существенного изменения

Принятые решения

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

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

Поэтому:

  1. инициализируем среду сборки (BUILDDIR)
  2. конфигурируем дистрибутив (make в каталоге профиля, пишет в BUILDDIR)
  3. конфигурируем среду сборки (./configure в BUILDDIR)
  4. выполняем собственно сборку (make в BUILDDIR)

r/o git

Сборка происходит вне собственно метапрофиля (максимум модификации — симлинк в сборочный каталог, если он r/w). Этим достигается дистрибутивность дистрибутивного профиля (возможна сборка прямо из /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/

  1. плоская, как сейчас (при этом тегированные списки вынесены в подкаталог tagged/)
    • довольно просто реализуется и ничто не должно ломаться
  2. иерархическая — например, base/server
    • должно быть более масштабируемым даже при переходе многих пакаджлистов на теги

взаимодействие тегированных списков и pkg/groups

Пока совсем неясно, потребуется рассмотрение активными пользователями alterator-pkg.

Пожелания к коллегам

строгое обращение с потоками данных

Желательно направление движения значений переменных и действий короткими шагами «сверху вниз» — без выдёргивания значений из соседних каталогов или путешествий сверху в самый низ различным образом).

Построение списков пакетов «на лету» обдумывается, но не подобными хаками, а скорее такими (см. создание .base; также реализована выборка пакаджлистов по произвольным булевым выражениям, включающим теги).

унификация

Крайне желательно неразведение зоопарка аналогов (например, методов макроподстановки). Если вводятся новые практики или концепции, лучше предварительно обсудить задумку или реализацию в своём бранче next до того, как на новосделанное будет завязано много ценного. Если возникают конфликты мнений — давайте постараемся их разрешать, а не форкаться без планов на мерж.

повторное использование вместо дублирования

Также и в самих списках сколько получается — давайте стараться избежать дублирования, а вместо мини-форков выделять общее и отделять разное.

Если совсем какая-то специфика, но может пригодиться и другим (косясь на mithraen@ и asterisk-1.6.[012] в m-p-d) — может иметь смысл завести «свой» namespace для списков/фич.

построение вместо урезания

При возможности следует выбирать подход «построить из нужного», чем «добавить всякое и выбросить ненужное»: он гораздо лучше ложится на идею mkimage-profiles (создание из кусочков и минимизация непрозрачных хаков). Это позволяет надеяться на трассируемость процесса построения дистрибутива.

Вынужденным исключением на сейчас является субпрофиль install2 с зачисткой излишних модулей ядра и файлов в компактном livecd-корне инсталятора.

Объекты

дистрибутив

Цель вида distro/%, выполнение которой приводит к созданию конфигурации соответствующего дистрибутива, достаточной для построения его образа. Описываются в distro.mk (технические цели вынесены в libdistro.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;
  • подкаталоги по имени нужных субпрофилей, содержимое которых добавляется к содержимому включённых в дистрибутив субпрофилей;
  • generate.sh и/или generate.mk для постобработки.

пакаджлист

Файл со списком пакетов, размещённый в 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.

ARCH, APTCONF, MKIMAGE_PREFIX можно передать через ~/.mkimage/profiles.mk (autoconf вместе с ./configure исключён как класс по причине невостребованности).

Практически не втянуты pkg.in/groups/.

Спешки по части расширения ассортимента дистрибутива нет никакой, потихоньку делается база для комфортной работы релиз-менеджеров.

Ссылки