Mkimage-profiles/oldpage

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


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

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

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

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

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

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

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

унификация

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

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

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

Состояние

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

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

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

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