Mkimage-profiles/oldpage: различия между версиями

Материал из ALT Linux Wiki
(pkglists policy)
Строка 29: Строка 29:
=== r/o профиль ===
=== r/o профиль ===
Сборка происходит вне собственно профиля (максимум модификации — симлинк в сборочный каталог, если он r/w). Этим достигается дистрибутивность дистрибутивного профиля (возможна сборка прямо из {{path|/usr/share}}) и одновременно убирается риск коммитов сборочного мусора (подставленные <tt>.in</tt>-файлы и т. п.).
Сборка происходит вне собственно профиля (максимум модификации — симлинк в сборочный каталог, если он r/w). Этим достигается дистрибутивность дистрибутивного профиля (возможна сборка прямо из {{path|/usr/share}}) и одновременно убирается риск коммитов сборочного мусора (подставленные <tt>.in</tt>-файлы и т. п.).
=== формирование списков для субпрофилей ===
Создаётся единый конфигурационный makefile (.config.mk в корне сборочного каталога), в который при конфигурировании дистрибутива добавляются пары переменная-значение.  При этом возможно использование немедленных и отложенных подстановок переменных и до сих пор получилось избежать необходимости макроподстановок при помощи {{cmd|autoconf}}.
В сборочный каталог копируются только необходимые (перечисленные в переменных <tt>*_LISTS</tt>) пакаджлисты.
Списки тегов превращаются в списки пакаджлистов до передачи в <tt>BUILDDIR</tt>.


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


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

Версия от 20:58, 8 сентября 2010


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 заполнен статически).