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

Материал из ALT Linux Wiki
(→‎Под вопросом: +dynamic subprofiles)
Строка 50: Строка 50:
# надёргиваем нужные подкаталоги или даже файлы с тем, чтобы избежать возможности неявного использования скриптов и пакаджлистов из субпрофилей (ср. со сборкой rpm в хост-среде или в hasher chroot)
# надёргиваем нужные подкаталоги или даже файлы с тем, чтобы избежать возможности неявного использования скриптов и пакаджлистов из субпрофилей (ср. со сборкой rpm в хост-среде или в hasher chroot)
#* пока понятно относительно отдельных пакаджлистов и стадийных подкаталогов целиком
#* пока понятно относительно отдельных пакаджлистов и стадийных подкаталогов целиком
# копируем "как есть"
# копируем "как есть" (с точностью до макроподстановок)


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

Версия от 14:11, 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-файлы и т. п.).

Под вопросом

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

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

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

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