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.

Под вопросом

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

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. копируем "как есть" (с точностью до макроподстановок)

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

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

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

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

унификация

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

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

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

Состояние

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

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

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

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