Mkimage-profiles/oldpage

mkimage-profiles.git

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

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

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

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

Цели

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

Design decisions

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

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

Поэтому:

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

r/o профиль

Сборка происходит вне собственно профиля (максимум модификации — симлинк в сборочный каталог, если он r/w). Этим достигается дистрибутивность дистрибутивного профиля (возможна сборка прямо из /usr/share) и одновременно убирается риск коммитов сборочного мусора (подставленные .in-файлы и т. п.).

метапрофиль -> профиль -> образ

Желательно, чтобы порождённые профили были полностью самостоятельными.

формирование списков для субпрофилей

Создаётся единый конфигурационный makefile (.config.mk в корне сборочного каталога), в который при конфигурировании дистрибутива добавляются пары переменная-значение. При этом возможно использование немедленных и отложенных подстановок переменных и до сих пор получилось избежать необходимости макроподстановок при помощи autoconf.

В сборочный каталог копируются только необходимые (перечисленные в переменных *_LISTS) пакаджлисты. Субпрофили различаются по префиксам имён переменных, в которые укладываются относящиеся к ним сущности: INSTALL2_PACKAGES, BASE_LISTS… в одном toplevel .config.mk

Списки тегов превращаются в списки пакаджлистов до передачи в BUILDDIR.

субпрофили и pkg/* в сборочном каталоге

Из метапрофиля в профиль попадают только нужные каталоги субпрофилей/фич и только нужные пакаджлисты — с тем, чтобы избежать возможности неявного использования объектов из «грязной» среды (ср. со сборкой rpm в хост-среде или в 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

Выбор:

1. передавать через переменные make
2. определить, что это переменные времени конфигурирования сборочного профиля, и заниматься ими в сгенерированном профиле (звучит вроде логично, но красиво реализовать у меня пока не получилось)

сделан в пользу инициализации небольшого количества дефолтов перед сборкой конфигурации и возможности добавления локального metaconf.mk в самом её конце (отчасти уже давно, но финализировано после детального обсуждения с Алексеем Чеусовым).

Под вопросом

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

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

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

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

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

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

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

Построение списков пакетов «на лету» обдумывается, но не подобными хаками, а скорее такими (или по тегам, реализация в процессе).

унификация

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

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

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

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

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

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

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

Объекты

дистрибутив

Цель вида distro/%, выполнение которой приводит к созданию конфигурации дистрибутива, достаточной для построения его образа. Описываются в distro.mk; могут наследовать друг другу. Пример -- distro/server-light.

субпрофиль

Цель вида sub/%, выполнение которой приводит к созданию базовой конфигурации соответствующего цельного блока для укладки в образ (например, sub/rescue). Описаны в distro.mk в общем виде.

фича

Цель вида use/%, снабжённая подкаталогом в features/. В подкаталоге может быть:

• кусочек конфигурации в виде makefile, автоматически включаемый в distro.mk
• подкаталог ..., копируемый ...

пакаджлист

Файл со списком пакетов, размещённый в pkg.in/lists/. Упоминается в генерируемом файле конфигурации дистрибутива (.config.mk) в переменных %_LISTS; перечисленные списки копируются в создаваемый профиль дистрибутива на стадии make config ###.

Состояние

На конец весны 2011 реализован профиль минималистичного серверного дистрибутива, растущего в сторону server-light.cd, из которого при помощи make server-light.iso собирается устанавливающийся инсталлер, из которого получается загружающаяся система.

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

Не втянуты pkg/groups (.base заполнен статически).

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