Введение. При установке системы используются профили и группы установщика. Они позволяют пользователю задать нужный ему набор функций устанавливаемой системы просто выбрав группы. В установщике и при первом запуске установленной системы выполняются скрипты, производящие окончательную настройку. После установки эта простота теряется - для добавления нужных функций требуется знать какие конкретно пакеты ставить и как выполнять настройку системы. Для сохранения простоты добавления функций в установленную систему разрабатываются компоненты. Компоненты хранятся в пакетах, содержат списки пакетов и методы настройки системы. Для разных продуктов нужны разные наборы функций и, следовательно, наборы компонентов. Эти наборы хранятся в пакетах редакций. Для использования компонентов без доступа к сетевым репо нужно, чтобы все пакеты, описанные в нужных компонентах, были доступны из самого образа. Для этого при сборке образа нужно взять из редакций компоненты, из компонентов пакеты и все их добавить в образ. Описание исправлений. Добавлена утилита mkimage tools/mki-alt-components-extract и переменная EDITION_PACKAGES. Переменная EDITION_PACKAGES содержит список пакетов для установки в инструментальный чрут сабпрофиля main. Эта переменная заполняется в сборочном профиле mkimage-profiles и передаётся mkimage в features.in/build-distro/lib/90-build-distro.mk Утилита mki-alt-components-extract вызывается в рецепте цели copy-packages перед копированием пакетов в репо образа. В ней происходит: - доустановка нужных пакетов (редакций, компонент, скриптов для их обработки) в инструментальный чрут субпрофиля main; - разбор текстовых списков компонент в редакциях и пакетов в компонентах; - формирование списка пакетов, которые должны попасть в репо образа; - выдача списка пакетов для копирования в репо образа. Если переменная EDITION_PACKAGES пуста, то в образ ничего не добавляется. Исправления для mkimage представлены в коммите: https://git.altlinux.org/people/jqt4/packages/?p=mkimage.git;a=commitdiff;h=4db483a18cd4978a8da02c0fa08864d01ab8344a Прошу рассмотреть.
> Если переменная EDITION_PACKAGES пуста, то в образ ничего не добавляется. Но mki-alt-components-extract, и editions2packages в нём, всё равно будут вызваны? Как это работает на профилях, которые ничего не знают про редакции? Вообще, я ожидал более общего решения. Чтобы не только список пакетов для чрута, но и команда, взываемая в нём, были частью профиля. А то получается странная история, что профиль должен подобрать пакеты, в которых будет указаный в исходниках mkimage исполняемый файл.
(In reply to Ivan A. Melnikov from comment #1) > Вообще, я ожидал более общего решения. Чтобы не только список пакетов для > чрута, но и команда, взываемая в нём, были частью профиля. А то получается > странная история, что профиль должен подобрать пакеты, в которых будет > указаный в исходниках mkimage исполняемый файл. Вычисляемый набор пакетов. Мы просто переменную задаём в профиле, а пакеты приезжают те, что в компоненте прописаны. Почему должно быть иначе? И как должно быть иначе? А вот то, что это не документировано в mkimage, неправильно. Надо обязательно добавить в документацию про переменную EDITION_PACKAGES. Те, кто не используют mkimage-profiles, также могут задействовать эту переменную в своём Makefile.
(Ответ для Ivan A. Melnikov на комментарий #1) > > Если переменная EDITION_PACKAGES пуста, то в образ ничего не добавляется. > > Но mki-alt-components-extract, и editions2packages в нём, всё равно будут > вызваны? Как это работает на профилях, которые ничего не знают про редакции? Тестировал такой сценарий В лог сборки выдано что-то подобное: mkimage: Processing 'copy-packages' ... mki-cache: has started executing. mki-install: has started executing. /.host/entry: line 10: exec: editions2packages: not found Сборке образа не помешало. > > Вообще, я ожидал более общего решения. Чтобы не только список пакетов для > чрута, но и команда, взываемая в нём, были частью профиля. А то получается > странная история, что профиль должен подобрать пакеты, в которых будет > указаный в исходниках mkimage исполняемый файл.
(In reply to jqt4@altlinux.org from comment #3) > (Ответ для Ivan A. Melnikov на комментарий #1) > > > Если переменная EDITION_PACKAGES пуста, то в образ ничего не добавляется. > > > > Но mki-alt-components-extract, и editions2packages в нём, всё равно будут > > вызваны? Как это работает на профилях, которые ничего не знают про редакции? > Тестировал такой сценарий > В лог сборки выдано что-то подобное: > > mkimage: Processing 'copy-packages' ... > mki-cache: has started executing. > mki-install: has started executing. > /.host/entry: line 10: exec: editions2packages: not found > > Сборке образа не помешало. Да. Такое не годится.
(In reply to Антон Мидюков from comment #2) > (In reply to Ivan A. Melnikov from comment #1) >> Вообще, я ожидал более общего решения [...] > Вычисляемый набор пакетов. Мы просто переменную задаём в профиле, а пакеты > приезжают те, что в компоненте прописаны. Почему должно быть иначе? И как > должно быть иначе? Я имелл в виду, что mkimage не обязательно что-то знать про редакции, а редакциям про mkimage. Вычисляемый набор пакетов может в теории быть полезен и за пределами редакций. Можно, например, задавать в профиле не только EDITION_PACKAGES (что поставить в chroot), но и EDITION_COMMAND (что выполнить в чруте). Так мы даём возможность разработчикам редакций возможность переименовать бинарник editions2packages во что-то ещё (мало ли что им в голову придёт) не ломая mkimage, а только профили; возможность разработчикам профилей передать в эту команду дополнительные опции (а есть ощущение, что они понадобятся в будущем) и вообще получаем достаточно общий и гибкий инструмент. Надо только подумать над nameing'ом. Ему не обязательно даже содержать слово EDITION.
(Ответ для Ivan A. Melnikov на комментарий #5) > (In reply to Антон Мидюков from comment #2) > > (In reply to Ivan A. Melnikov from comment #1) > >> Вообще, я ожидал более общего решения [...] > > Вычисляемый набор пакетов. Мы просто переменную задаём в профиле, а пакеты > > приезжают те, что в компоненте прописаны. Почему должно быть иначе? И как > > должно быть иначе? > > Я имелл в виду, что mkimage не обязательно что-то знать про редакции, а > редакциям про mkimage. > > Вычисляемый набор пакетов может в теории быть полезен и за пределами > редакций. > > Можно, например, задавать в профиле не только EDITION_PACKAGES (что > поставить в chroot), но и EDITION_COMMAND (что выполнить в чруте). Так мы > даём возможность разработчикам редакций возможность переименовать бинарник > editions2packages во что-то ещё (мало ли что им в голову придёт) не ломая > mkimage, а только профили; возможность разработчикам профилей передать в эту > команду дополнительные опции (а есть ощущение, что они понадобятся в > будущем) и вообще получаем достаточно общий и гибкий инструмент. > > Надо только подумать над nameing'ом. Ему не обязательно даже содержать слово > EDITION. https://git.altlinux.org/people/jqt4/packages/?p=mkimage.git;a=commitdiff;h=ef47c1eb268218b0e268929d2a15d97b42178f4e Сделал название более общим, добавил переменную для команды. Если любая переменная не заполнена скрипт завершится без ошибки и в лог ничего не напишет. Добавил описание переменных в документацию.
(In reply to jqt4@altlinux.org from comment #6) > https://git.altlinux.org/people/jqt4/packages/?p=mkimage.git;a=commitdiff; > h=ef47c1eb268218b0e268929d2a15d97b42178f4e > Сделал название более общим, добавил переменную для команды. > Если любая переменная не заполнена скрипт завершится без ошибки и в лог > ничего не напишет. > Добавил описание переменных в документацию. Спасибо! Небольшой вопрос: > [ -z "$pkgs" -o -z "$cmds" ] && exit 0 Надо ли здесь проверять пакеты на пустоту, если команда задана?
(Ответ для Ivan A. Melnikov на комментарий #7) ... > Спасибо! > > Небольшой вопрос: > > > [ -z "$pkgs" -o -z "$cmds" ] && exit 0 > > Надо ли здесь проверять пакеты на пустоту, если команда задана? Согласен, здесь не нужно. Нужно перед установкой пакетов. Исправил. Также убрал кавычки, чтобы воспринимались аргументы команды. https://git.altlinux.org/people/jqt4/packages/?p=mkimage.git;a=commitdiff;h=87406a2b670151b3f7c1eef36b4cde3c502e7276
Прошу рассмотреть исправления, и если нет возражений и замечаний, принять.
Собрал исправления в 1 коммит: https://git.altlinux.org/people/jqt4/packages/mkimage.git?p=mkimage.git;a=commitdiff;h=e5a7dd29ce0f9f7796e045ac53eded7c611441c3 Собрал исправленный mkimage в задаче 382775 Прошу сделать approve
Добрый день, коллеги, подскажите, как скоро удастся принять данные изменения?
Я посмотрел на патч и он выглядит сейчас как хак. Прежде чем обсуждать, как сделать это решение не хаком, хочется спросить нужно ли нам вообще такое решение на уровне mkimage. mkimage уже сейчас поддерживает механизм SUBDIRS, позволяющий создать отдельный инструментальный чрут и сделать в нём вообще всё что угодно. Получить список, который потом можно использовать в качестве файла передаваемого в IMAGE_PACKAGES не должно быть проблемой.
(Ответ для Gleb F-Malinovskiy на комментарий #12) > Я посмотрел на патч и он выглядит сейчас как хак. > > Прежде чем обсуждать, как сделать это решение не хаком, хочется спросить > нужно ли нам вообще такое решение на уровне mkimage. mkimage уже сейчас > поддерживает механизм SUBDIRS, позволяющий создать отдельный > инструментальный чрут и сделать в нём вообще всё что угодно. Получить > список, который потом можно использовать в качестве файла передаваемого в > IMAGE_PACKAGES не должно быть проблемой. Такое решение кажется мне нужным и оправданным. Хотелось бы сделать надёжный инструмент в mkimage, который будет работать годами и не будет привязан к mkimage-profiles. Компоненты хотелось бы задействовать в будущем не только для субпрофиля main (репозиторий на диске) в mkimage-profiles, но и для live и rootfs. Городить для каждого субпрофиля по субпрофилю в mkimage-profiles мне кажется неудобным.
(In reply to Антон Мидюков from comment #13) > Компоненты хотелось бы задействовать в будущем не только для субпрофиля main > (репозиторий на диске) в mkimage-profiles, но и для live и rootfs. Это как раз одна из вещей, почему сейчас это сейчас хак: если так делать, то сразу делать единообразно -- и для copy-packages и для build-image. В любом случае, если посмотреть глубже названий переменных и скрипта, то что реализовано это запуск произвольного кода внутри инструментального чрута, предназначенного для сборки образа. > Городить для каждого субпрофиля по субпрофилю в mkimage-profiles мне кажется > неудобным. Для каждого это для main и rootfs?
