(В ответ на комментарий №0)
> 2. Среди установлеваемых пакетов не должно быть гостевых драйверов
> virtualbox`а-- сильно мешают тестировать полученный дистрибутив
> в VirtualBox`овой же виртуалке.
А кто их принёс? (посмотри по build/distcfg.mk или расскажи, от какого образа отталкивался -- regular-server, так понимаю)

(В ответ на комментарий №1)
> (В ответ на комментарий №0)
> > 2. Среди установлеваемых пакетов не должно быть гостевых драйверов
> > virtualbox`а-- сильно мешают тестировать полученный дистрибутив
> > в VirtualBox`овой же виртуалке.
> А кто их принёс? (посмотри по build/distcfg.mk или расскажи, от какого образа
> отталкивался -- regular-server, так понимаю)

Нет, у меня в основе distro/regular-xfce (даёт хорошую основу для последующего отрезания лишнего). Но в конечном итоге (когда функционал устаканится) основу придётся менять -- слишком много лишнего в дистрибутив попадает (тот же firefox, к примеру).

Сейчас (в период бутстрапа) цепочка зависимостей следующая: distro/regular-xfce <- distro/.regular-desktop <- distro/.regular-wm <- distro/.regular-wm  <- distro/.regular-x11 <- +vmguest.

(В ответ на комментарий №2)
> Нет, у меня в основе distro/regular-xfce (даёт хорошую основу
> для последующего отрезания лишнего).
Вообще в m-p идеология построения, а не отчекрыживания -- сформулируй требования (нужно ли DE или предполагается исключительно удалённый/безголовый запуск?), затем найди наиболее близкий к нему образ БЕЗ необходимости что-либо из него выкидывать; если "почти такой", то можно из данной цели выделить "техническую" промежуточную (см. вывод git grep -F distro/.), подцепив к ней взятую за основу цель с тем, чтобы сама она не изменилась, и свою новую, которая при этом будет содержать всё то, что ты вынес в промежуточную, и не обязана содержать всё, что было в "почти подходящей".

Разумеется, если добавка закопана глубоко в дереве наследования, так не выйдет.

regular-* вообще не очень хорошая база для того, что должно расти "вбок", а не надстраиваться над ними, потому что в них включено довольно много функциональности по постановке задачи; более компактные примеры есть в conf.d/{desktop,live,server}.mk, только вот distro/.server-base включает use/cleanup/x11-alterator, а тот выносит libX* и qt4-common, среди прочего...

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

(В ответ на комментарий №3)
> (В ответ на комментарий №2)
> > Нет, у меня в основе distro/regular-xfce (даёт хорошую основу
> > для последующего отрезания лишнего).
> Вообще в m-p идеология построения, а не отчекрыживания -- сформулируй
> требования (нужно ли DE или предполагается исключительно удалённый/безголовый
> запуск?), затем найди наиболее близкий к нему образ БЕЗ необходимости что-либо
> из него выкидывать; если "почти такой", то можно из данной цели выделить
> "техническую" промежуточную (см. вывод git grep -F distro/.), подцепив к ней
> взятую за основу цель с тем, чтобы сама она не изменилась, и свою новую,
> которая при этом будет содержать всё то, что ты вынес в промежуточную, и не
> обязана содержать всё, что было в "почти подходящей".

  Примерно по такому пути и собираюсь двигаться. Но этот путь потребует вдумчивого анализа каждой из подключаемых фич. На данном же этапе -- мне нужен прообраз рабочего прототипа. (К созданию оного с 0 пока неготов: в межфичном взаимодействии ещё плоховато ориентируюсь. В дальнейшем -- буду приводить его к нужному виду, методом последовательных приближений.)

> 
> Разумеется, если добавка закопана глубоко в дереве наследования, так не выйдет.

Это вижу, по структуре зависимостей между целями сборки. Но пока, без работающего прототипа, непонятно что вообще нужно, кроме основного функционала...

> 
> Так что давай-ка расскажи постановку задачи по образу и сделаем как положено,
> на сегодняшний выпуск целиться уже не буду.

OK.

Основная задача -- получить инсталлятор графической пускалки для VirtualBox`а (и управляющего им софта). При этом:

1. Обычные пользователи -- имеют доступ только к заданному множеству VM из под сильно кастрированного openbox`а.

2. Всем этим хозяйством управляет администратор, работающий из под Xfce.

+ в конечном итоге в систему не должно подать ничего лишнего. Но пока непонятно что именно считать лишним... Список лишнего будет получен в процессе исследования прототипа.

Created attachment 6387 [details]
рефакторинг server.mk с добавлением distro/server-vbox

Собственно, если сделать

distro/server-vbox: distro/server-mini use/server/vbox; @:

и собрать его -- то после завершения установки пакет virtualbox будет отсутствовать, останется только virtualbox-common; поэтому сделал по мотивам вышепредложенного proof-of-concept без X-сервера, прилагаю (он же проверен без добавленных тобой CLEANUP_PACKAGES, которые я склонен считать относящимися к конкретному образу скорее, чем к предложенной фиче -- если не сделать use/vmguest/vbox или в ручном эквиваленте, то никто выбрасываемые модули в образ и не положит).

(В ответ на комментарий №4)
> Основная задача -- получить инсталлятор графической пускалки для VirtualBox`а
> (и управляющего им софта). При этом:
> 
> 1. Обычные пользователи -- имеют доступ только к заданному множеству VM из под
> сильно кастрированного openbox`а.
Если ничего от WM и не надо -- можно ещё посмотреть на ratpoison, см. применение в livecd-webkiosk.

> 2. Всем этим хозяйством управляет администратор, работающий из под Xfce.
Так это не сервер, а десктоп.  Собственно, не стоит и в фичу добавлять, и даже группу разводить на ровном месте -- просто опиши образ, в который добавь virtualbox.  И всё. :)

> + в конечном итоге в систему не должно подать ничего лишнего.
> Но пока непонятно что именно считать лишним...
EFI, kernel-modules-*, спасательные пакеты/списки?..

Ещё для понимания может быть полезно внимательное изучение build/distcfg.mk.

PS: возможно, Сергей решал отчасти перекликающиеся задачи, на всякий подписываю.

(В ответ на комментарий №5)
> Created an attachment (id=6387) [details]
> рефакторинг server.mk с добавлением distro/server-vbox
> 
> Собственно, если сделать
> 
> distro/server-vbox: distro/server-mini use/server/vbox; @:
> 
> и собрать его -- то после завершения установки пакет virtualbox будет
> отсутствовать, останется только virtualbox-common; поэтому сделал по мотивам
> вышепредложенного proof-of-concept без X-сервера, прилагаю (он же проверен без
> добавленных тобой CLEANUP_PACKAGES, которые я склонен считать относящимися к
> конкретному образу скорее, чем к предложенной фиче -- если не сделать
> use/vmguest/vbox или в ручном эквиваленте, то никто выбрасываемые модули в
> образ и не положит).

Такое решение выглядит достаточно красивым.

CLEANUP_PACKAGES позволяет быстро приложить фичу к любому десктопному distro/* и оценить полученный результат. Что, на мой взгляд -- заметно экономит время создания начального варианта прототипа.

(В ответ на комментарий №6)
> (В ответ на комментарий №4)
> > Основная задача -- получить инсталлятор графической пускалки для VirtualBox`а
> > (и управляющего им софта). При этом:
> > 
> > 1. Обычные пользователи -- имеют доступ только к заданному множеству VM из под
> > сильно кастрированного openbox`а.
> Если ничего от WM и не надо -- можно ещё посмотреть на ratpoison, см.
> применение в livecd-webkiosk.

  Нужна корректная работа мультимониторной конфигурации. (Есть подводные камни, как оказалось.)

> 
> > 2. Всем этим хозяйством управляет администратор, работающий из под Xfce.
> Так это не сервер, а десктоп.  Собственно, не стоит и в фичу добавлять, и даже
> группу разводить на ровном месте -- просто опиши образ, в который добавь
> virtualbox.  И всё. :)

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

> 
> > + в конечном итоге в систему не должно подать ничего лишнего.
> > Но пока непонятно что именно считать лишним...
> EFI, kernel-modules-*, спасательные пакеты/списки?..

  Ага. + всякая мультимедиа.

(В ответ на комментарий №6)
> PS: возможно, Сергей решал отчасти перекликающиеся задачи, на всякий
> подписываю.
Если бы решал, то решение уже бы было. Но впопыхах чёткого ТЗ не было, поэтому держал в уме несколько вариантов. В итоге от этого варианта полностью отказались (точнее, дальше наброска дело не пошло, хотя сам набросок вполне себе работал). PS Да, там было отличие от предлагаемого здесь варианта: в iso включался заранее подготовленный образ системы, который требовалось запускать в headless режиме при запуске развернутого на машине iso-шника.

(В ответ на комментарий №7)
> CLEANUP_PACKAGES позволяет быстро приложить фичу к любому десктопному distro/*
> и оценить полученный результат. Что, на мой взгляд -- заметно экономит время
> создания начального варианта прототипа.
Ну это всё-таки для оценки, а не для мержа, согласись. :)

У меня тоже куча мелких веточек с кучками временных коммитов, некоторые из которых дозревают до cherry-pick или merge...

(В ответ на комментарий №8)
> Нужна корректная работа мультимониторной конфигурации.
> (Есть подводные камни, как оказалось.)
В своё время сталкивался с некоторыми, но это уже не про m-p, почтой пиши.

> > > Но пока непонятно что именно считать лишним...
> > EFI, kernel-modules-*, спасательные пакеты/списки?..
> Ага. + всякая мультимедиа.
Если у тебя есть жёсткое ТЗ, то может быть лучше отталкиваться от совсем базовых целей вроде distro/.installer и формировать по списку -- см. тот же regular-jeos (там CLEANUP_PACKAGES обусловлены неоптимальностями пакетной базы и отсутствием возможности пометить и удалить начисто пакеты, временно установленные для работы инсталятора).

В m-p изначально заложено много точек выбора между уже готовым, но неконтролируемым заимствуемым и тем, что описываешь врукопашную, зато и гарантируешь...

См. тж.:
https://www.altlinux.org/Mkimage/Profiles/m-p/howto
https://www.altlinux.org/Mkimage/Profiles/m-p/objects

2 sb: понял, спасибо.

(В ответ на комментарий №10)
> (В ответ на комментарий №7)
> > CLEANUP_PACKAGES позволяет быстро приложить фичу к любому десктопному distro/*
> > и оценить полученный результат. Что, на мой взгляд -- заметно экономит время
> > создания начального варианта прототипа.
> Ну это всё-таки для оценки, а не для мержа, согласись. :)

Не, не соглашусь. :-)

Основное назначение данной фичи -- гарантированое исключение ситуации, когда гостевой и серверный драйвера имеют возможность загрузится одновременно, т. к. при этом в виртуалке ломаются X`ы. (У нас не тестировал, но на Fedora такой слом был стабильным, см. https://bugzilla.rpmfusion.org/show_bug.cgi?id=3425.) Так что, для меня ценность данной фичи очевидна. Но настаивать что оно важно всем (и потому обязательно должно быть в в пакете) -- не буду. :-)

> 
> В m-p изначально заложено много точек выбора между уже готовым, но
> неконтролируемым заимствуемым и тем, что описываешь врукопашную, зато и
> гарантируешь...

И в этом плане он сильно удобней Fedora`овской anaconda...