Mkimage-profiles/objects: различия между версиями
(исправлен путь conf/*.mk -> conf.d/*.mk) |
м (MichaelShigorin переименовал страницу Mkimage/Profiles/m-p/objects в Mkimage-profiles/objects: на своё место :-)) |
||
(не показана 1 промежуточная версия 1 участника) | |||
Строка 7: | Строка 7: | ||
Цель вида <tt>distro/%</tt>, <tt>ve/%</tt> либо <tt>vm/%</tt>, выполнение которой приводит к созданию конфигурации соответствующего дистрибутива или виртуального окружения, достаточной для построения его образа. Описываются в {{path|conf.d/*.mk}} (базовые заданы в {{path|lib/distro.mk}}, {{path|lib/ve.mk}}, {{path|lib/vm.mk}}); могут наследовать друг другу. Пример — <tt>distro/server-ovz</tt>. | Цель вида <tt>distro/%</tt>, <tt>ve/%</tt> либо <tt>vm/%</tt>, выполнение которой приводит к созданию конфигурации соответствующего дистрибутива или виртуального окружения, достаточной для построения его образа. Описываются в {{path|conf.d/*.mk}} (базовые заданы в {{path|lib/distro.mk}}, {{path|lib/ve.mk}}, {{path|lib/vm.mk}}); могут наследовать друг другу. Пример — <tt>distro/server-ovz</tt>. | ||
Для своего образа (или группы образов) рекомендуется создать новый файл по образцу имеющихся {{path|conf/*.mk}} и описывать конфигурацию в нём; это позволит избежать конфликтов при обновлении базового репозитория (например, по {{cmd|git pull}}). | Для своего образа (или группы образов) рекомендуется создать новый файл по образцу имеющихся {{path|conf.d/*.mk}} и описывать конфигурацию в нём; это позволит избежать конфликтов при обновлении базового репозитория (например, по {{cmd|git pull}}). | ||
== субпрофиль == | == субпрофиль == |
Текущая версия от 18:10, 10 декабря 2020
Объекты mkimage-profiles
Как правило, более тщательно задокументированы в README из каталога с реализацией.
Обратите внимание: список приведён в порядке убывающей суммарной сложности объекта; если надо добавить пакет — достаточно добавить пакет (например, в THE_PACKAGES); если несколько — можно и в подходящий список; устойчивую группу настроек можно вынести в mixin-цель; а фичу следует заводить тогда, когда необходимо добавить скрипты либо сгруппировать конфигурацию под предметную область для повторного использования (как, например, в фиче server).
образ
Цель вида distro/%, ve/% либо vm/%, выполнение которой приводит к созданию конфигурации соответствующего дистрибутива или виртуального окружения, достаточной для построения его образа. Описываются в conf.d/*.mk (базовые заданы в lib/distro.mk, lib/ve.mk, lib/vm.mk); могут наследовать друг другу. Пример — distro/server-ovz.
Для своего образа (или группы образов) рекомендуется создать новый файл по образцу имеющихся conf.d/*.mk и описывать конфигурацию в нём; это позволит избежать конфликтов при обновлении базового репозитория (например, по git pull).
субпрофиль
Цель вида sub/%, выполнение которой приводит к созданию базовой конфигурации соответствующего цельного блока для укладки в образ дистрибутива (например, sub/install2). Описаны в lib/distro.mk в общем виде, размещаются в sub.in/.
Обратите внимание: sub/stage2 является базовым, а не самостоятельным, и используется посредством use/stage2/* для получения итоговых субпрофилей install2, live, rescue; цели sub/stage2/* являются техническими, не следует ставить их в зависимости дистрибутивов.
фича
Цель вида use/%, снабжённая подкаталогом в features.in/. В подкаталоге может быть:
- кусочек конфигурации в виде config.mk, автоматически включаемый в toplevel Makefile;
- подкаталоги по имени нужных субпрофилей, содержимое которых добавляется к содержимому включённых в дистрибутив субпрофилей (rootfs является особым случаем, см. sub.in/rootfs/README;
- подкаталоги image-scripts.d/ и scripts.d/, скрипты из которых добавляются в toplevel-каталог сборки (см. пример в features.in/syslinux/scripts.d/);
- generate.sh и/или generate.mk для постобработки;
- включаемый в сборочный каталог lib/ для фич, определяющих сборку образа (build-*).
пакаджлист
Файл со списком пакетов, размещённый в pkg.in/lists/. Упоминается в генерируемом файле конфигурации дистрибутива (distcfg.mk) в переменных %_LISTS; перечисленные списки копируются в создаваемый профиль дистрибутива на стадии порождения дистрибутивного профиля.
Может быть тегированным (tagged/) — см. lib/functions.mk::tags(), bin/tags2lists, features.in/rescue/config.mk по реализации и применению.
Списки пакетов обычно есть смысл выделять в файлы либо при повторном использовании, либо при заметном объёме, когда перечисление прямо в конфигурации сильно снижает её читаемость (предлагаемое «правило большого пальца» — если набралось больше пары строк добавок в одну переменную вроде THE_PACKAGES, стоит обдумать вынесение в файл).