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)