Mkimage-profiles/oldpage

mkimage-profiles.git

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

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

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

Будет опубликован для обсуждения перед дальнейшими планированием и разработкой, как только станет хоть немного полезен и чуть пыль осядет. В идеале хотелось бы успеть пересадить на него Centaurus.

Цели

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

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) пакаджлисты.

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

phony targets

Сейчас сделан выбор стиля «все цели являются липовыми», то есть им не соответствуют существующие или создаваемые каталоги/файлы. Обоснование: когда неочевидно, что какой-либо цели соответствует объект ФС, отладка может затрудниться тем, что make не будет пересоздавать такой объект, если не обновлялись его prerequisites (которые обычно оказываются phony). При этом цена вопроса безусловного пересоздания любой цели на этапе конфигурирования пренебрежимо мала — максимум единицы секунд.

Когда-то в будущем может возыметь смысл переработка mkimage и mkimage-profiles с использованием честных файловых зависимостей и более тесной интеграцией, но это вне рамок данного проекта.

Под вопросом

именование включаемых конфигов и переменных в них

1. «различаем стадии по префиксам имён переменных, в которые укладываются относящиеся к ним сущности в одном конфиге»
   • INSTALL2_PACKAGES, BASE_LISTS… в одном toplevel .config.mk
2. «различаем стадии по тому, в каком субпрофиле лежит частный конфиг (и подключаем также и общий)»
   • PACKAGES, LISTS в install2/.stage-cfg.mk, main/.stage-cfg.mk…

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

1. надёргиваем нужные подкаталоги или даже файлы с тем, чтобы избежать возможности неявного использования скриптов и пакаджлистов из субпрофилей (ср. со сборкой rpm в хост-среде или в hasher chroot)
   • пока понятно относительно отдельных пакаджлистов и стадийных подкаталогов целиком
2. копируем "как есть" (с точностью до макроподстановок)

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

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

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

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

propagator+syslinux

1. создаём отдельную стадию stage1 в явном виде (аналогично install2), переносим propagator и syslinux туда; в корне собираемого профиля оставляем только сборку образа (и, возможно, Metadata)
   • это даже получилось, но +10 сек ко времени сборки example3 на E5420/tmpfs
2. всё как в m-p-d и example[12] -- первая стадия не совсем явно порождается прямо в корневом каталоге сборочного профиля, незагрузочные образы создаются хаками вроде отдельных субпрофилей и зачистки лишнего

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

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

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

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

унификация

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

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

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

Объекты

дистрибутив

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

субпрофиль

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

фича

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

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

пакаджлист

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

Состояние

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

Вокнуты гвозди (то, что в m-p-d на configure):

• arch
• apt-conf
• kernel flavour
• mkimage prefix

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