Mkimage-profiles/oldpage

mkimage-profiles.git

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

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

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

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

Цели

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

Design decisions

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

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

Поэтому:

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

r/o профиль

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

Под вопросом

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

«скармливаем субпрофильным makefile уже подготовленную конфигурацию»
- список пакаджлистов разбирается чем-то между конфигурацией дистрибутива и сборкой образа (make config?)
- подготавливаются image.in{,/*}/packages непосредственно со списками пакетов (NB: дублируем работу mkimage?)
- создаётся .base и копируются нужные для pkg-groups.tar списки
«скармливаем имена пакетов и пакаджлистов, предоставляем субпрофилям возможность надёргать нужное из полного набора»
- передаются имена в том числе и пакаджлистов
- создаётся симлинк или копия pkg/ в сборочном каталоге

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

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

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

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

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

унификация

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

Состояние

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

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

arch
apt-conf
kernel flavour
mkimage prefix

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