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

Материал из ALT Linux Wiki
м (→‎mkimage-profiles.git: -тавтология)
м (MichaelShigorin переименовал страницу Mkimage/Profiles/m-p/oldpage в Mkimage-profiles/oldpage: на своё место :-))
 
(не показаны 33 промежуточные версии этого же участника)
Строка 1: Строка 1:
[[Категория:Mkimage]]
[[Категория:Mkimage-profiles]]


== mkimage-profiles.git ==
= quickstart =
# выполняем инструкции по [http://git.altlinux.org/people/mike/public/?p=mkimage-profiles.git;a=blob;f=QUICKSTART;hb=HEAD документации]
# {{cmd|git clone git://git.altlinux.org/people/mike/public/mkimage-profiles.git}}
# {{cmd|cd mkimage-profiles}}
# {{cmd|make distro/icewm.iso}}
 
= mkimage-profiles.git =
__TOC__
 
== Предыстория ==
К 2010 году с [[Mkimage/Profiles/Desktop|mkimage-profiles-desktop]] накопились следующие проблемы:
К 2010 году с [[Mkimage/Profiles/Desktop|mkimage-profiles-desktop]] накопились следующие проблемы:
* очень объёмный и сложный профиль, освоение требует значительных сил и времени;
* очень объёмный и сложный профиль, освоение требует значительных сил и времени;
Строка 9: Строка 18:
Поэтому решил попытаться нарисовать новый профиль, который бы также позволял собирать различные десктопные и серверные iso/flash-образы, но и учитывал бы обнаруженные проблемы (в том числе более полно соответствовал [[WhiteLabel|изначальной задумке]]).
Поэтому решил попытаться нарисовать новый профиль, который бы также позволял собирать различные десктопные и серверные iso/flash-образы, но и учитывал бы обнаруженные проблемы (в том числе более полно соответствовал [[WhiteLabel|изначальной задумке]]).


Профиль [http://git.altlinux.org/people/mike/public/?p=mkimage-profiles.git опубликован] для обсуждения перед дальнейшими планированием и разработкой, поскольку уже хоть немного полезен и пыль начала оседать. Просьба не воспринимать историю как постоянную — первые десятки коммитов делались как технические и предполагалась зачистка всех этих метаний по достижении некоторой точки.
Получившийся по факту ''метапрофиль'' (репозиторий запчастей для построения дистрибутивов) [http://git.altlinux.org/people/mike/public/?p=mkimage-profiles.git опубликован].  Следует иметь в виду, что первые десятки коммитов делались как технические и по достижении состояния твёрдой беты для публикации в packages/ были переработаны относительно начисто (архив в подлиннике всё так же доступен в public/).


== Цели ==
== Цели ==
Строка 16: Строка 25:
* документированность: изначальная и каждого существенного изменения
* документированность: изначальная и каждого существенного изменения


== Design decisions ==
== Принятые решения ==


=== раздельные стадии конфигурации и сборки ===
=== раздельные стадии конфигурации и сборки ===
Строка 27: Строка 36:
# выполняем собственно сборку ({{cmd|make}} в <tt>BUILDDIR</tt>)
# выполняем собственно сборку ({{cmd|make}} в <tt>BUILDDIR</tt>)


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


метапрофиль -> профиль -> образ
Схема: '''метапрофиль => профиль => образ'''


Желательно, чтобы порождённые профили были полностью самостоятельными.
Порождённые профили являются полностью самостоятельными.


=== формирование списков для субпрофилей ===
=== формирование списков для субпрофилей ===
Создаётся единый конфигурационный makefile (.config.mk в корне сборочного каталога), в который при конфигурировании дистрибутива добавляются пары переменная-значение.  При этом возможно использование немедленных и отложенных подстановок переменных и до сих пор получилось избежать необходимости макроподстановок при помощи {{cmd|autoconf}}.
Создаётся единый конфигурационный makefile ({{path|distcfg.mk}} в корне сборочного каталога), в который при конфигурировании дистрибутива добавляются пары переменная-значение.  При этом возможно использование немедленных и отложенных подстановок переменных и до сих пор получилось избежать необходимости макроподстановок при помощи {{cmd|autoconf}}.


В сборочный каталог копируются только необходимые (перечисленные в переменных <tt>*_LISTS</tt>) пакаджлисты.  Субпрофили различаются по префиксам имён переменных, в которые укладываются относящиеся к ним сущности: <tt>INSTALL2_PACKAGES</tt>, <tt>BASE_LISTS</tt>… в одном toplevel {{path|.config.mk}}
В сборочный каталог копируются только необходимые (перечисленные в переменных <tt>*_LISTS</tt>) пакаджлисты.  Субпрофили различаются по префиксам имён переменных, в которые укладываются относящиеся к ним сущности: <tt>INSTALL2_PACKAGES</tt>, <tt>BASE_LISTS</tt>… в одном toplevel {{path|distcfg.mk}}.


Списки тегов превращаются в списки пакаджлистов до передачи в <tt>BUILDDIR</tt>.
Списки тегов превращаются в списки пакаджлистов до передачи в <tt>BUILDDIR</tt>.


=== субпрофили и pkg/* в сборочном каталоге ===
=== субпрофили и пакаджлисты в сборочном каталоге ===
Из метапрофиля в профиль попадают только нужные каталоги субпрофилей/фич и только нужные пакаджлисты — с тем, чтобы избежать возможности неявного использования объектов из «грязной» среды (ср. со сборкой rpm в хост-среде или в hasher chroot).
Из метапрофиля в профиль попадают только нужные каталоги субпрофилей/фич и только нужные пакаджлисты — с тем, чтобы избежать возможности неявного использования объектов из «грязной» среды (ср. со сборкой пакета в хост-системе или в hasher chroot).


=== phony targets ===
=== phony targets ===
Строка 53: Строка 62:


=== make+shell vs autoconf ===
=== make+shell vs autoconf ===
Выбор:
Выбор сделан в пользу инициализации небольшого количества дефолтов перед сборкой конфигурации и возможности добавления локального {{path|profiles.mk}} в самом её конце (отчасти уже давно, но финализировано после детального обсуждения с Алексеем Чеусовым).
# '''передавать через переменные {{cmd|make}}'''
 
# определить, что это переменные времени конфигурирования ''сборочного'' профиля, и заниматься ими в сгенерированном профиле (звучит вроде логично, но красиво реализовать у меня пока не получилось)
При этом основополагающая информация (<tt>BUILDDIR</tt>) передаётся через переменные {{cmd|make}}, а конфигурация будущего дистрибутива собирается во включаемый конфигурационный файл в корне генерируемого дистрибутивного профиля, который затем используется в процессе генерации профиля и сборки по нему дистрибутива.
сделан в пользу инициализации небольшого количества дефолтов перед сборкой конфигурации и возможности добавления локального {{path|metaconf.mk}} в самом её конце (отчасти уже давно, но финализировано после детального обсуждения с Алексеем Чеусовым).


== Под вопросом ==
== Под вопросом ==


=== структура подкаталога lists/ ===
=== структура подкаталога lists/ ===
# плоская, как сейчас (при этом тегированные списки отделены namespace’ом _* и не пересекаюся по именам с существующими)
# плоская, как сейчас (при этом тегированные списки вынесены в подкаталог {{path|tagged/}})
#* довольно просто реализуется и ничто не должно ломаться
#* довольно просто реализуется и ничто не должно ломаться
# иерархическая — например, base/server
# иерархическая — например, base/server
Строка 68: Строка 76:
=== взаимодействие тегированных списков и pkg/groups ===
=== взаимодействие тегированных списков и pkg/groups ===
Пока совсем неясно, потребуется рассмотрение активными пользователями [[alterator-pkg]].
Пока совсем неясно, потребуется рассмотрение активными пользователями [[alterator-pkg]].
=== тегированные скрипты ===
Имеется первичная реализация (см. {{path|features.in/Makefile}}), поддерживающая выборку скриптов из {{path|features.in/$feat/tagged/{image-,}scripts.d/}} по набору тегов, который сейчас состоит из названия фичи (например, <tt>cleanup</tt>) и названия/названий стадии (например, <tt>install2 || stage2</tt>).
* внятный и удобный механизм конструирования полезных запросов пока не придуман
* похоже, есть смысл сделать переменные-коллекторы, в которые автоматически попадают списки имён, производные от конфигурации дистрибутива или его частей (частичный пример см. в виде <tt>dirtags</tt> в {{path|features.in/Makefile}})
=== зачистка ===
Крайне неприятная тема: профиль нацелен на инкрементальное построение, а зачистка идёт против этого принципа (даже если строить её саму инкрементально).  Бродят разные мысли:
* списки вроде <tt>KEEP_PATHS</tt>, <tt>KEEP_PACKAGES</tt> с тем, чтобы проверять их значения и не удалять указанное в cleanup-скриптах;
* изначально брать полный набор cleanup'ов для заданных стадий, но ''вычитать'' из них (тегами или на крайний случай {{cmd|tags2lists | xargs rm}}) инкрементально построенный список того, что должно остаться.  В [http://www.lic145.kiev.ua/ школе] говорили, что минус на минус даёт плюс ;-)


== Пожелания к коллегам ==
== Пожелания к коллегам ==
Строка 74: Строка 92:
Желательно направление движения значений переменных и действий короткими шагами «сверху вниз» — без выдёргивания значений из [http://git.altlinux.org/people/mike/packages/?p=mkimage-profiles-desktop.git;a=blob;f=profiles/scripts.d/03-syslinux;h=640947f18adb189ad97396903ea64087f293d25a;hb=refs/heads/p5#l9 соседних каталогов] или путешествий сверху в самый низ [http://git.altlinux.org/people/mike/packages/?p=mkimage-profiles-desktop.git;a=blob;f=profiles/pkg/lists/kde3-lite.in;h=de04b344aed4b615afe4abc1e2d103608dac9793;hb=refs/heads/p5#l21 различным] [http://git.altlinux.org/people/mike/packages/?p=mkimage-profiles-desktop.git;a=blob;f=use.mk.in;h=26db334ae35398b5eab431b175a87baf83a1b8ab;hb=refs/heads/p5#l237 образом]).
Желательно направление движения значений переменных и действий короткими шагами «сверху вниз» — без выдёргивания значений из [http://git.altlinux.org/people/mike/packages/?p=mkimage-profiles-desktop.git;a=blob;f=profiles/scripts.d/03-syslinux;h=640947f18adb189ad97396903ea64087f293d25a;hb=refs/heads/p5#l9 соседних каталогов] или путешествий сверху в самый низ [http://git.altlinux.org/people/mike/packages/?p=mkimage-profiles-desktop.git;a=blob;f=profiles/pkg/lists/kde3-lite.in;h=de04b344aed4b615afe4abc1e2d103608dac9793;hb=refs/heads/p5#l21 различным] [http://git.altlinux.org/people/mike/packages/?p=mkimage-profiles-desktop.git;a=blob;f=use.mk.in;h=26db334ae35398b5eab431b175a87baf83a1b8ab;hb=refs/heads/p5#l237 образом]).


Построение списков пакетов «на лету» обдумывается, но не [http://git.altlinux.org/people/mike/packages/?p=mkimage-profiles-desktop.git;a=blob;f=use.mk.in;h=7741dee9360a40f59c865f24eb09d6e173e9859c;hb=HEAD#l229 подобными хаками], а скорее [http://git.altlinux.org/people/enp/packages/?p=mkimage-profile-live.git;a=blob;f=live/features-setup;h=0d18ea801eb5c9124e1a1aec3a268dbaba769754;hb=refs/heads/autoconf такими] (или по тегам, реализация в процессе).
Построение списков пакетов «на лету» обдумывается, но не [http://git.altlinux.org/people/mike/packages/?p=mkimage-profiles-desktop.git;a=blob;f=use.mk.in;h=7741dee9360a40f59c865f24eb09d6e173e9859c;hb=HEAD#l229 подобными хаками], а скорее [http://git.altlinux.org/people/enp/packages/?p=mkimage-profile-live.git;a=blob;f=live/features-setup;h=0d18ea801eb5c9124e1a1aec3a268dbaba769754;hb=refs/heads/autoconf такими] (см. [http://git.altlinux.org/people/mike/public/?p=mkimage-profiles.git;a=blob;f=pkg.in/lists/Makefile;h=18c7f4e0033af61bb4715b525e600f6409100523;hb=HEAD#l19 создание .base]; также [http://git.altlinux.org/people/mike/public/?p=mkimage-profiles.git;a=blob;f=bin/tags2lists;hb=HEAD реализована] выборка пакаджлистов по произвольным булевым выражениям, включающим теги).


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


=== повторное использование вместо дублирования ===
=== повторное использование вместо дублирования ===
Строка 87: Строка 105:
При возможности следует выбирать подход «построить из нужного», чем «добавить всякое и выбросить ненужное»: он гораздо лучше ложится на идею mkimage-profiles (создание из кусочков и минимизация непрозрачных хаков).  Это позволяет надеяться на трассируемость процесса построения дистрибутива.
При возможности следует выбирать подход «построить из нужного», чем «добавить всякое и выбросить ненужное»: он гораздо лучше ложится на идею mkimage-profiles (создание из кусочков и минимизация непрозрачных хаков).  Это позволяет надеяться на трассируемость процесса построения дистрибутива.


Вынужденным исключением на сейчас является субпрофиль <tt>install2</tt> с зачисткой излишних модулей ядра и файлов в компактном livecd-корне инсталятора.
Вынужденным исключением на сейчас являются:
* фича <tt>install2</tt> с зачисткой излишних модулей ядра и файлов в компактном livecd-корне инсталятора;
* фича <tt>cleanup</tt>, подготавливающая постинсталяционную зачистку лишних пакетов в свежеустановленной системе.


== Объекты ==
== Объекты ==
=== дистрибутив ===
=== дистрибутив ===
Цель вида <tt>distro/%</tt>, выполнение которой приводит к созданию конфигурации дистрибутива, достаточной для построения его образа. Описываются в distro.mk; могут наследовать друг другу. Пример -- <tt>distro/server-light</tt>.
Цель вида <tt>distro/%</tt>, выполнение которой приводит к созданию конфигурации соответствующего дистрибутива, достаточной для построения его образа. Описываются в {{path|distro.mk}}; могут наследовать друг другу. Пример — <tt>distro/server-ovz</tt>.


=== субпрофиль ===
=== субпрофиль ===
Цель вида <tt>sub/%</tt>, выполнение которой приводит к созданию базовой конфигурации соответствующего цельного блока для укладки в образ (например, <tt>sub/rescue</tt>).  Описаны в distro.mk в общем виде.
Цель вида <tt>sub/%</tt>, выполнение которой приводит к созданию базовой конфигурации соответствующего цельного блока для укладки в образ (например, <tt>sub/install2</tt>).  Описаны в {{path|libdistro.mk}} в общем виде, размещаются в {{path|sub.in/}}.
 
Обратите внимание: <tt>sub/stage2</tt> является базовым, а не самостоятельным, и используется посредством <tt>use/stage2/*</tt> для получения итоговых субпрофилей install2, live, rescue.  <tt>sub/stage2/*</tt> являются техническими, не следует ставить их в зависимости дистрибутивов.


=== фича ===
=== фича ===
Цель вида <tt>use/%</tt>, снабжённая подкаталогом в {{path|features/}}.  В подкаталоге может быть:
Цель вида <tt>use/%</tt>, снабжённая подкаталогом в {{path|features.in/}}.  В подкаталоге может быть:
* кусочек конфигурации в виде makefile, автоматически включаемый в distro.mk
* кусочек конфигурации в виде {{path|config.mk}}, автоматически включаемый в {{path|distro.mk}};
* подкаталог ..., копируемый ...
* подкаталоги по имени нужных субпрофилей, содержимое которых добавляется к содержимому включённых в дистрибутив субпрофилей;
* подкаталоги {{path|image-scripts.d/}} и {{path|scripts.d/}}, скрипты из которых добавляются в toplevel-каталог сборки (см. пример в {{path|features.in/syslinux/scripts.d/}});
* {{path|generate.sh}} и/или {{path|generate.mk}} для постобработки;
* включаемый в сборочный каталог {{path|lib/}} для фич, определяющих сборку образа (<tt>build-*</tt>).
 
В экспериментальном порядке рядом со {{path|*scripts.d/}} [http://git.altlinux.org/people/mike/public/?p=mkimage-profiles.git;a=commitdiff;h=ec0b0ef375b3206b27ea0890d09c579d9ffdcbbf;hp=8326eebd28a5f660a43ea2d02b174c20ed486777 обрабатываются] {{path|tagged/{image-,}scripts.d/*}}, см. в качестве примера {{path|features.in/cleanup/tagged/image-scripts.d/01+install2+cleanup}}.


=== пакаджлист ===
=== пакаджлист ===
Файл со списком пакетов, размещённый в {{path|pkg.in/lists/}}.  Упоминается в генерируемом файле конфигурации дистрибутива (.config.mk) в переменных %_LISTS; перечисленные списки копируются в создаваемый профиль дистрибутива на стадии make config ###.
Файл со списком пакетов, размещённый в {{path|pkg.in/lists/}}.  Упоминается в генерируемом файле конфигурации дистрибутива ({{path|distcfg.mk}}) в переменных <tt>%_LISTS</tt>; перечисленные списки копируются в создаваемый профиль дистрибутива на стадии порождения дистрибутивного профиля.
 
Может быть ''тегированным'' ({{path|tagged/}}) — см. {{path|lib/functions.mk}}<tt>::tags()</tt>, {{path|bin/tags2lists}}, {{path|features.in/rescue/config.mk}} по реализации и применению.


== Состояние ==
== Состояние ==
На конец весны 2011 реализован профиль минималистичного серверного дистрибутива, растущего в сторону <tt>server-light.cd</tt>, из которого при помощи {{cmd|make server-light.iso}} собирается устанавливающийся инсталлер, из которого получается загружающаяся система.
Ноябрь 2011: реализован и упакован метапрофиль, при помощи которого можно собрать несколько минималистичных дистрибутивов и шаблонов виртуальных окружений:
* {{cmd|make distro/server-ovz.iso}} или {{cmd|make distro/icewm.iso}} соберёт устанавливающийся инсталлер, из которого получается загружающаяся система;
* {{cmd|make distro/rescue.iso}} и {{cmd|make distro/live-builder.iso}} — небольшую спасательную систему и «живую сборочницу», соответственно <small>(последняя способна собрать себя сама при доступности интернета либо <tt>distro/syslinux.iso</tt> — автономно)</small>;
* {{cmd|make ve/generic.tar}} и {{cmd|make ve/openvpn.tgz}} — компактный чрут для [[OpenVZ]] (вероятно, и LXC) и его же с OpenVPN.
При этих операциях заодно получается более-меее аккуратно сформированный git-репозиторий, содержащий дистрибутивный профиль по принципу --as-needed.


<tt>ARCH</tt>, <tt>APTCONF</tt>, <tt>MKIMAGE_PREFIX</tt> можно передать через {{path|~/.mkimage/metaconf.mk}} ({{pkg|autoconf}} вместе с {{cmd|./configure}} исключён как класс по причине невостребованности).
Сделаны и применяются тегированные пакаджлисты и скриптовые хуки выборкой по произвольным булевым выражениям).


Не втянуты {{path|pkg/groups}} ({{path|.base}} заполнен статически).
Практически не втянуты {{path|pkg.in/groups/}}.


<tt>ARCH</tt>, <tt>APTCONF</tt>, <tt>MKIMAGE_PREFIX</tt> (см. {{path|doc/variables.txt}}) можно передать в командной строке либо рутинно через {{path|~/.mkimage/profiles.mk}}; {{pkg|autoconf}} вместе с {{cmd|./configure}} исключён как класс по причине непригодности для задач, подразумевающих наследование.
=== сроки ===
Спешки по части расширения ассортимента дистрибутива нет никакой, потихоньку делается база для комфортной работы релиз-менеджеров.
Спешки по части расширения ассортимента дистрибутива нет никакой, потихоньку делается база для комфортной работы релиз-менеджеров.
== Ссылки ==
* [http://www.perforce.com/perforce/conferences/us/2005/presentations/NvidiaPresentation.pdf презентация] и [http://www.perforce.com/perforce/conferences/us/2005/presentations/NvidiaPaper.pdf статья] nvidia, использующих perforce+makepp в качестве средств configuration management
* [http://search.cpan.org/~agent/Makefile-GraphViz/lib/Makefile/GraphViz.pm Makefile::Graphviz] и [http://search.cpan.org/~agent/Makefile-GraphViz/script/gvmake gvmake] — визуализация зависимостей в makefiles

Текущая версия от 18:10, 10 декабря 2020


quickstart

  1. выполняем инструкции по документации
  2. git clone git://git.altlinux.org/people/mike/public/mkimage-profiles.git
  3. cd mkimage-profiles
  4. make distro/icewm.iso

mkimage-profiles.git

Предыстория

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

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

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

Получившийся по факту метапрофиль (репозиторий запчастей для построения дистрибутивов) опубликован. Следует иметь в виду, что первые десятки коммитов делались как технические и по достижении состояния твёрдой беты для публикации в packages/ были переработаны относительно начисто (архив в подлиннике всё так же доступен в public/).

Цели

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

Принятые решения

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

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

Поэтому:

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

r/o git

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

Схема: метапрофиль => профиль => образ

Порождённые профили являются полностью самостоятельными.

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

Создаётся единый конфигурационный makefile (distcfg.mk в корне сборочного каталога), в который при конфигурировании дистрибутива добавляются пары переменная-значение. При этом возможно использование немедленных и отложенных подстановок переменных и до сих пор получилось избежать необходимости макроподстановок при помощи autoconf.

В сборочный каталог копируются только необходимые (перечисленные в переменных *_LISTS) пакаджлисты. Субпрофили различаются по префиксам имён переменных, в которые укладываются относящиеся к ним сущности: INSTALL2_PACKAGES, BASE_LISTS… в одном toplevel distcfg.mk.

Списки тегов превращаются в списки пакаджлистов до передачи в BUILDDIR.

субпрофили и пакаджлисты в сборочном каталоге

Из метапрофиля в профиль попадают только нужные каталоги субпрофилей/фич и только нужные пакаджлисты — с тем, чтобы избежать возможности неявного использования объектов из «грязной» среды (ср. со сборкой пакета в хост-системе или в hasher chroot).

phony targets

Сейчас сделан выбор стиля «все цели являются липовыми», то есть им не соответствуют существующие или создаваемые каталоги/файлы. Обоснование: когда неочевидно, что какой-либо цели соответствует объект ФС, отладка может затрудниться тем, что make не будет пересоздавать такой объект, если не обновлялись его prerequisites (которые обычно оказываются phony). При этом цена вопроса безусловного пересоздания любой цели на этапе конфигурирования пренебрежимо мала — максимум единицы секунд.

Когда-то в будущем может возыметь смысл переработка mkimage и mkimage-profiles с использованием честных файловых зависимостей и более тесной интеграцией, но это вне рамок данного проекта.

propagator+syslinux = stage1

Каждый субпрофиль создаётся, конфигурируется и применяется в явном виде. Так, создан субпрофиль stage1 (аналогично install2 и всем им соответствуют подкаталоги sub.in/*/), куда перенесена подготовка propagator и syslinux; в корне собираемого профиля — только сборка образа (сейчас — также Metadata, .disk/* и индексов репозиториев), см. image.in/Makefile.

make+shell vs autoconf

Выбор сделан в пользу инициализации небольшого количества дефолтов перед сборкой конфигурации и возможности добавления локального profiles.mk в самом её конце (отчасти уже давно, но финализировано после детального обсуждения с Алексеем Чеусовым).

При этом основополагающая информация (BUILDDIR) передаётся через переменные make, а конфигурация будущего дистрибутива собирается во включаемый конфигурационный файл в корне генерируемого дистрибутивного профиля, который затем используется в процессе генерации профиля и сборки по нему дистрибутива.

Под вопросом

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

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

взаимодействие тегированных списков и pkg/groups

Пока совсем неясно, потребуется рассмотрение активными пользователями alterator-pkg.

тегированные скрипты

Имеется первичная реализация (см. features.in/Makefile), поддерживающая выборку скриптов из features.in/$feat/tagged/{image-,}scripts.d/ по набору тегов, который сейчас состоит из названия фичи (например, cleanup) и названия/названий стадии (например, install2 || stage2).

  • внятный и удобный механизм конструирования полезных запросов пока не придуман
  • похоже, есть смысл сделать переменные-коллекторы, в которые автоматически попадают списки имён, производные от конфигурации дистрибутива или его частей (частичный пример см. в виде dirtags в features.in/Makefile)

зачистка

Крайне неприятная тема: профиль нацелен на инкрементальное построение, а зачистка идёт против этого принципа (даже если строить её саму инкрементально). Бродят разные мысли:

  • списки вроде KEEP_PATHS, KEEP_PACKAGES с тем, чтобы проверять их значения и не удалять указанное в cleanup-скриптах;
  • изначально брать полный набор cleanup'ов для заданных стадий, но вычитать из них (тегами или на крайний случай tags2lists ) инкрементально построенный список того, что должно остаться. В школе говорили, что минус на минус даёт плюс ;-)

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

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

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

Построение списков пакетов «на лету» обдумывается, но не подобными хаками, а скорее такими (см. создание .base; также реализована выборка пакаджлистов по произвольным булевым выражениям, включающим теги).

унификация

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

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

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

Если совсем какая-то специфика, но может пригодиться и другим (косясь на mithraen@ и asterisk-1.6.[012] в m-p-d) — может иметь смысл завести «свой» namespace для списков/фич.

построение вместо урезания

При возможности следует выбирать подход «построить из нужного», чем «добавить всякое и выбросить ненужное»: он гораздо лучше ложится на идею mkimage-profiles (создание из кусочков и минимизация непрозрачных хаков). Это позволяет надеяться на трассируемость процесса построения дистрибутива.

Вынужденным исключением на сейчас являются:

  • фича install2 с зачисткой излишних модулей ядра и файлов в компактном livecd-корне инсталятора;
  • фича cleanup, подготавливающая постинсталяционную зачистку лишних пакетов в свежеустановленной системе.

Объекты

дистрибутив

Цель вида distro/%, выполнение которой приводит к созданию конфигурации соответствующего дистрибутива, достаточной для построения его образа. Описываются в distro.mk; могут наследовать друг другу. Пример — distro/server-ovz.

субпрофиль

Цель вида sub/%, выполнение которой приводит к созданию базовой конфигурации соответствующего цельного блока для укладки в образ (например, sub/install2). Описаны в libdistro.mk в общем виде, размещаются в sub.in/.

Обратите внимание: sub/stage2 является базовым, а не самостоятельным, и используется посредством use/stage2/* для получения итоговых субпрофилей install2, live, rescue. sub/stage2/* являются техническими, не следует ставить их в зависимости дистрибутивов.

фича

Цель вида use/%, снабжённая подкаталогом в features.in/. В подкаталоге может быть:

  • кусочек конфигурации в виде config.mk, автоматически включаемый в distro.mk;
  • подкаталоги по имени нужных субпрофилей, содержимое которых добавляется к содержимому включённых в дистрибутив субпрофилей;
  • подкаталоги image-scripts.d/ и scripts.d/, скрипты из которых добавляются в toplevel-каталог сборки (см. пример в features.in/syslinux/scripts.d/);
  • generate.sh и/или generate.mk для постобработки;
  • включаемый в сборочный каталог lib/ для фич, определяющих сборку образа (build-*).

В экспериментальном порядке рядом со *scripts.d/ обрабатываются tagged/{image-,}scripts.d/*, см. в качестве примера features.in/cleanup/tagged/image-scripts.d/01+install2+cleanup.

пакаджлист

Файл со списком пакетов, размещённый в pkg.in/lists/. Упоминается в генерируемом файле конфигурации дистрибутива (distcfg.mk) в переменных %_LISTS; перечисленные списки копируются в создаваемый профиль дистрибутива на стадии порождения дистрибутивного профиля.

Может быть тегированным (tagged/) — см. lib/functions.mk::tags(), bin/tags2lists, features.in/rescue/config.mk по реализации и применению.

Состояние

Ноябрь 2011: реализован и упакован метапрофиль, при помощи которого можно собрать несколько минималистичных дистрибутивов и шаблонов виртуальных окружений:

  • make distro/server-ovz.iso или make distro/icewm.iso соберёт устанавливающийся инсталлер, из которого получается загружающаяся система;
  • make distro/rescue.iso и make distro/live-builder.iso — небольшую спасательную систему и «живую сборочницу», соответственно (последняя способна собрать себя сама при доступности интернета либо distro/syslinux.iso — автономно);
  • make ve/generic.tar и make ve/openvpn.tgz — компактный чрут для OpenVZ (вероятно, и LXC) и его же с OpenVPN.

При этих операциях заодно получается более-меее аккуратно сформированный git-репозиторий, содержащий дистрибутивный профиль по принципу --as-needed.

Сделаны и применяются тегированные пакаджлисты и скриптовые хуки (с выборкой по произвольным булевым выражениям).

Практически не втянуты pkg.in/groups/.

ARCH, APTCONF, MKIMAGE_PREFIX (см. doc/variables.txt) можно передать в командной строке либо рутинно через ~/.mkimage/profiles.mk; autoconf вместе с ./configure исключён как класс по причине непригодности для задач, подразумевающих наследование.

сроки

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

Ссылки