Mkimage-Profiles и DistroNavigator, О gui для m-p Опции Поделиться

[ИВК]

Выделено из темы "Git"

А какая правка, можете патч показать или прислать почтой?

Файл conf.d/desktop.mk:

Код

25c25,28
< distro/tde: distro/.desktop-network +tde; @:
---
> distro/tde-t7: distro/.desktop-network +tde; @:
> distro/tde-p7: distro/.desktop-network +tde; @:
> distro/tde-t6: distro/.desktop-network +tde; @:
> distro/tde-p6: distro/.desktop-network +tde; @:

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

Код

tde-mini.cd: | use-tde-mini install2 main install-cd.@IMAGETYPE@

на подобные этой:

Код

tde-mini-@BRANCH<>cd: | use-tde-mini-@BRANCH@ install2 main install-cd.@IMAGETYPE@

а к именам файлов в profiles/pkg/lists добавил "-t7" и т.п., чтобы каждый из них можно было изменять, не трогая другие. Профили одного и того же дистра для разных бранчей должны быть сразу чётко и единообразно отделены друг от друга, иначе программа в них запутается.
Вообще, едва ли не бОльшая часть моих правок в m-p-d как раз с бранчами и связана. Если в m-p решить данную проблему как-то радикально, то потребность во всякого рода хаках сразу резко уменьшится.

[Michael Shigorin]

Файл conf.d/desktop.mk:

Код

-distro/tde: distro/.desktop-network +tde; @:
+distro/tde-t7: distro/.desktop-network +tde; @:
+distro/tde-p7: distro/.desktop-network +tde; @:
+distro/tde-t6: distro/.desktop-network +tde; @:
+distro/tde-p6: distro/.desktop-network +tde; @:

diff лучше применять с ключиком -u, так виднее :)

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

Не, так намучаетесь, это же постоянные изменения и конфликты на ровном месте.

Может быть лучше сделать примерно так, по крайней мере для m-p:
- фиксируем версию (тег) профиля, который проверяем -- например, v1.1.65 или v0.6.2.2;
- проверяем список образов, которые на заданном бранче собираются по этому состоянию профиля;
- пишем список в файлик, названный по версии, в отдельном каталоге;
- при запуске навигатора смотрим в этот каталог, берём "старший" файлик (сортировка по версиям);
- пытаемся склонировать репозиторий и смотрим, есть ли нужное в нём (git tag --list v1.1.65);
- если есть -- забираем из файлика список и показываем в меню, если нет -- берём следующий по старшинству файлик.

Предложение отчасти основывается на том, как собираю регулярки и стартовые наборы, там тоже есть по такому файлику:

Код

nightly@ ~ $ cat mkimage/flavours
cinnamon
e19
gnome3
gnustep
icewm
kde4
lxde
lxqt
mate
rescue
tde
wmaker
xfce

Если это всё сложно -- можно воспользоваться костылём, который пришлось сделать для сборки стартеркитов; мне он не нравится (и это значит, что когда-то он может быть и переделан), но, с другой стороны, пока альтернативы и не просматриваются.

Костыль выглядит как "прокси" для имён с изменением брендинга и живёт в conf.d/p7.mk (в бранче t6 существует conf.d/t6.mk с единственным дистрибутивом altlinux-t6-server-ovz, собранным по просьбе hiddenman@).

Соответственно при выборе ветки p7/t7 (тут уж придётся вручную "свести" варианты) можно делать git checkout 1.0 -- сейчас это та версия, которая упаковывается с соответствующие бранчи как пакет, хотя стартеркиты собираются на master (предполагается отпочковывание ветки 1.2 в районе p8); при выборе p6/t6 -- git checkout t6. Если пойдёт, то могу обеспечить наличие в гите ветки t7, которая, скорее всего, будет синонимом 1.0 на данный момент.

Чтобы получить список образов, достаточно сказать make help в каталоге верхнего уровня; только здесь есть такая штука: в master сделано исправление, чтоб выводило в одну колонку, если не на консоль; а в 1.0 и t6 и в конвейер выведет по колонкам (будет сложнее разбирать). Пробуйте на master и conf.d/p7.mk (например, make help | grep ^altlinux-p7), если устроит -- нужное изменение можно сбэкпортить на те ветки.

Да, для старта можно ещё проще: в m-p обеспечена сборка из readonly-каталога, так что можно просто Requires: mkimage-profiles (и себе локально поставить) да собираться в /usr/share/mkimage-profiles -- но тогда никаких git checkout и прочих git log/git tag, потому как там только "снимок" гита без его метаданных (веток, истории -- всего, кроме текущего состояния).

Профили одного и того же дистра для разных бранчей должны быть сразу чётко и единообразно отделены друг от друга, иначе программа в них запутается.
Вообще, едва ли не бОльшая часть моих правок в m-p-d как раз с бранчами и связана. Если в m-p решить данную проблему как-то радикально, то потребность во всякого рода хаках сразу резко уменьшится.

Здесь поддержка (файловых) бранчей репозитория выполнена в виде (гитовых) бранчей профиля плюс вот те "прокси".

Ряд переменных изначально предназначен для того, чтоб их можно было указать при вызове make (см. doc/params.txt). Не помню, получится ли так перебить BRANDING, можно попробовать что-то на сей счёт придумать; а для дополнения списков пользовательскими пакетами наиболее логичным вариантом выглядит такой:
- создаём файлик conf.d/distronavigator.mk;
- в нём наследуем выбранную пользователем цель (т.е. пишем строчку, например, distro/navigator-tde: distro/tde);
- а в "рецепте" пишем дополнение списков по строчке с табом на переменную, примерно так:

Код

        @$(call add,THE_PACKAGES,пользовательские пакеты через пробел)

THE_PACKAGES, как документировано в doc/pkglists.txt, подбираются во все места для обычного пользования -- т.е. они пойдут и вместе с более узкоспециализированными LIVE_PACKAGES, и в установку рядом с BASE_PACKAGES.

Кстати, там же можно и брендинг задать:

Код

        @$(call set,BRANDING,altlinux-starterkit)

[ИВК]

Я никоим образом не держусь за ту реализацию работы с m-p, которая сейчас есть в программе. Она просто черновая, сделанная по принципу "чтоб видно было, что это вообще как-то работает" И переделать её можно довольно быстро. Очевидно для меня и то, что копипастить целые профили для каждого бранча - варварство, а на деле надо делать иначе; но я же графическим интерфейсом занимаюсь, а не самими профилями, потому у меня с ними бардак.
Посмотрим, как выглядит работа со сборочной системой с точки зрения Навигатора, что ему мешает.
Допустим, человек решил собирать тот же tde.iso и на t7 и на p6. Понятно, что состав пакетов для разных бранечей может быть немного различаться. Поэтому создаются два проекта, отличающиеся тем, что у каждого свой список пакетов, которые надо добавить к общему tde-профилю или исключить из него. Навигатор должен предоставить юзеру возможность редактировать эти два проекта (фактически - всего лишь два упомянутых бранч-специфичных списка) раздельно и потом собрать на их основе два разных образа. И это всё. Как именно реализована такая возможность в m-p - Навигатору без разницы. Какие крючки будут торчать из m-p для этого - к тем я и прицеплю gui.
Второе. Есть такая вот проблема (в m-p-d; просто не вникал ещё, как с этим в m-p). К примеру, в m-p-d описание дистрибутива в Makefile.in:

Код

lxde-desktop-lite.cd: | use-lxde-lite ...

То есть сам дистр - lxde-desktop-lite, а use- у него - просто lxde-lite; и т.п. Для сравнения: у дистрибутива-t7.cd и основной файл профиля называется distrocreator-t7, и в use-mk.in он под тем же названием фигурирует, и в configure.ac. Это очень важно для Навагатора, ему гораздо проще работать, когда уже по названию дистрибутива можно элементарно вычислить всё остальное, что к нему относится. Нельзя ли сделать так, чтобы у каждого дистрибутива, который будет в Навигаторе в числе базовых, с этим было (хотя бы для Навигатора; это с помощью симлинков, наверное) такое же единообразие, как в примере с distrocreator'ом? Тогда добавлять в Навигатор поддержку новых базовых дистрибутивов станет очень просто.
И третье. Всё-таки основное назначение программы - собирать пользовательские дистрибутивы. Поэтому ключевой момент в ней - создание нового проекта на основе базового (или ранее созданного пользовательского же). А значит, нужно определиться с двумя вещами: какую именно информацию юзер должен вводить при создании нового проекта и какие команды должна выполнять программа при нажатии кнопки "Создать проект". Под это и сделаю секцию создания проекта в m-p.
Вот три основных вопроса. Если с ними разобраться, то дело в основном сделано. Останутся второстепенные детали типа проблемы с брендингом, работы с дополнительными группами пакетов и т.п.

[ИВК]

Наконец взялся за это всерьёз. Обстановка на данный момент такова.
В последней версии (0.6.2-alt7) используется апрельский m-p от Кости (потому что там есть WMSmall, без которого Навигатору никуда). И от себя добавил DistroCreator. К этому мои правки и сводятся. Хаков там нет.
Сейчас можно создавать проекты на основе базовых (а это DistroCreator, WMSmall, fvwm; можно ещё добавить, но успеется), редактировать и собирать. Во всяком случае, у меня собрались.
Впрочем, пока с m-p Навигатор не умеет делать многого, что умеет с m-p-d. Надо этот разрыв сокращать. Первым делом, пожалуй, следует приделать выбор типа целевого дистрибутива; просто не разобрался ещё, как именно это в m-p реализуется. Потом дополнительные группы пакетов. Ну и с брендингом придётся что-то придумывать. Раздельные профили для каждого бранча - потом, наверное.
В общем, по мере вникания в суть дела мои представления об очерёдности действий сильно меняются