[devel-distro] I: mkimage-profiles 1.1.70

[devel-distro] I: mkimage-profiles 1.1.70

[Michael Shigorin]

       	Здравствуйте.
Опять мелочи -- в stage2 добавлена проверка, что KFLAVOURS
соответствуют какие-либо ядра (иначе в случаях вроде сборки
со своим вариантом из доп. репозитория, но без APTCONF нужного
вида, процесс мог занять слишком много времени до заведомого
облома без внятной диагностики).

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel-distro] I: mkimage-profiles 1.1.70

[Leo-sp50]

20.07.2015, 22:34, "Michael Shigorin" <mike@altlinux.org>:
>                Здравствуйте.
> Опять мелочи -- в stage2 добавлена проверка, что KFLAVOURS
> соответствуют какие-либо ядра (иначе в случаях вроде сборки
> со своим вариантом из доп. репозитория, но без APTCONF нужного
> вида, процесс мог занять слишком много времени до заведомого
> облома без внятной диагностики).
>
> --
>  ---- WBR, Michael Shigorin / http://altlinux.org
>   ------ http://opennet.ru / http://anna-news.info
> _______________________________________________
> devel-distro mailing list
> devel-distro@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-distro


Привет.

Есть пара вопросов.

1. Возможно ли, и если возможно, то где это подредактировать в скриптах\настройках,
что-бы по команде :

make -C /usr/share/mkimage-profiles syslinux.iso

выполнялось так :

- в текущем каталоге, откуда запущена команда, 
в частности в домашнем каталоге пользователя от которого запущена сборка, 
проверяется наличие подкаталога syslinux.iso, 
если он есть, то сборка продолжается по тому описания профиля, что есть в этом подкаталоге, 
если такого подкаталога с профилем нет, то создаётся подкаталог с именем собираемого дистра 
и  в нём формируется сборочный профиль на основании описания из /usr/share/mkimage-profiles
- сама сборка дистра идёт как обычно в tmp
- результат сохраняется в созданном подкаталоге syslinux.iso/out 

2. Возможно ли добавить что-то на подобие оболочки для m-p, с набором простых команд, например 

 mp clon syslinux.iso test-syslinux.iso 
 
будет создавать сборочный клон профиля из исходного профиля (/usr/share/mkimage-profiles) syslinux.iso с именем test-syslinux.iso

mp create syslinux.iso 

будет собирать на основе данных в /usr/share/mkimage-profiles указанный образ , что-бы не требовалось вводить полный
путь к /usr/share/mkimage-profiles. Что-бы это подразумевалось изначально в самой команде или описывалось в настроечном файле,
какой каталог использовать как исходный, установленный из rpm пакета или клонированный из git.

[devel-distro] о создании производных целей в m-p (было: I: mkimage-profiles 1.1.70)

[Michael Shigorin]

On Wed, Jul 22, 2015 at 12:54:50PM +0300, Leo-sp50 wrote:
> 1. Возможно ли, и если возможно, то где это подредактировать в
> скриптах\настройках, что-бы по команде :
> 
> make -C /usr/share/mkimage-profiles syslinux.iso
> 
> выполнялось так :
> - в текущем каталоге, откуда запущена команда, 
> в частности в домашнем каталоге пользователя от которого
> запущена сборка, проверяется наличие подкаталога syslinux.iso,
> если он есть, то сборка продолжается по тому описания профиля,
> что есть в этом подкаталоге, если такого подкаталога с профилем
> нет, то создаётся подкаталог с именем собираемого дистра и
> в нём формируется сборочный профиль на основании описания
> из /usr/share/mkimage-profiles

Возможно, только для этого надо или перекурочить main.mk,
или сделать себе предположительно достаточно простой скрипт-
обёртку, который выполнит вышеописанное.  А зачем именно такие
замудрения понадобились?

> - сама сборка дистра идёт как обычно в tmp

Там сложнее, см. lib/profile.mk и bin/mktmpdir :)

> - результат сохраняется в созданном подкаталоге syslinux.iso/out 

Для этого надо создать этот каталог и передать путь к нему
в переменной IMAGEDIR -- см. тж. lib/build.mk и image.in/Makefile

> 2. Возможно ли добавить что-то на подобие оболочки для m-p,
> с набором простых команд, например 
> 
>  mp clon syslinux.iso test-syslinux.iso 
>  
> будет создавать сборочный клон профиля из исходного профиля
> (/usr/share/mkimage-profiles) syslinux.iso с именем
> test-syslinux.iso

Вообще-то идея mkimage-profiles как раз в том, чтоб не
приходилось устраивать мульёны клонов _профиля_, а максимум
генерировать _заготовки_ для ручной допилки (в случае, если
результат нужен строго один раз и затем профиль на выброс):
такой заготовкой и является сборочный каталог, особенно при
CHECK=1, чтоб сама сборка не запускалась.

То есть для работы с профилем "на запись" предлагается не
копировать пакетный /usr/share/mkimage-profiles, а клонировать
git://git.altlinux.org/gears/m/mkimage-profiles.git и работать
именно с гит-репозиторием, при необходимости доводя наработки
до вида, пригодного к вливанию назад в проект.

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

> mp create syslinux.iso 
> 
> будет собирать на основе данных в /usr/share/mkimage-profiles
> указанный образ , что-бы не требовалось вводить полный путь к
> /usr/share/mkimage-profiles. Что-бы это подразумевалось
> изначально в самой команде или описывалось в настроечном файле,
> какой каталог использовать как исходный, установленный из rpm
> пакета или клонированный из git.

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

Начиная от "есть m-p, в нём нет такой-то цели, мне нужно".

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel-distro] о создании производных целей в m-p (было: I: mkimage-profiles 1.1.70)

[Leo-sp50]

> Возможно, только для этого надо или перекурочить main.mk,
> или сделать себе предположительно достаточно простой скрипт-
> обёртку, который выполнит вышеописанное. А зачем именно такие
> замудрения понадобились?
>
Для  live-builder .
Если пользоваться клоном гита m-p - не понятно зачем тогда
в образе нужен /usr/share/mkimage-profile


> Там сложнее, см. lib/profile.mk и bin/mktmpdir :)
>
>>  - результат сохраняется в созданном подкаталоге syslinux.iso/out
>
> Для этого надо создать этот каталог и передать путь к нему
> в переменной IMAGEDIR -- см. тж. lib/build.mk и image.in/Makefile
>
Понятно, посмотрю.


> Вообще-то идея mkimage-profiles как раз в том, чтоб не
> приходилось устраивать мульёны клонов _профиля_, а максимум
> генерировать _заготовки_ для ручной допилки (в случае, если
> результат нужен строго один раз и затем профиль на выброс):
> такой заготовкой и является сборочный каталог, особенно при
> CHECK=1, чтоб сама сборка не запускалась.
>
Эт если один раз поиграться с одним образом. 
А если  работать с несколькими разными и параллельно и не один день ?


> То есть для работы с профилем "на запись" предлагается не
> копировать пакетный /usr/share/mkimage-profiles, а клонировать
> git://git.altlinux.org/gears/m/mkimage-profiles.git и работать
> именно с гит-репозиторием, при необходимости доводя наработки
> до вида, пригодного к вливанию назад в проект.
>
> См. тж. http://www.altlinux.org/Mkimage/Profiles/m-p/howto
>
Речь не про копирование всего m-p, а "вытаскивание" для последующего ковыряния
конкретно того, что касается только одного образа. И что-бы эти "заготовки" можно было
чётко идентифицировать, и дальше, когда будет отлажено точно, что нужно получить\изменить в них,
тогда можно  отдавать для других.


> Давай определимся с тем, какую задачу ты пытаешься решить
> -- пока описываемый путь выглядит сильно неоптимальным,
> если правильно понимаю, о чём вообще речь.
>
> Начиная от "есть m-p, в нём нет такой-то цели, мне нужно".
>
Если бы я точно знал, что мне может понадобиться завтра .... :)

Re: [devel-distro] о создании производных целей в m-p

[Michael Shigorin]

On Wed, Jul 22, 2015 at 05:48:08PM +0300, Leo-sp50 wrote:
> > Возможно, только для этого надо или перекурочить main.mk,
> > или сделать себе предположительно достаточно простой скрипт-
> > обёртку, который выполнит вышеописанное. А зачем именно такие
> > замудрения понадобились?
> Для  live-builder .  Если пользоваться клоном гита m-p - не
> понятно зачем тогда в образе нужен /usr/share/mkimage-profile

Чтоб был под рукой офлайновый вариант -- для этого же и RPMS.main
в объёме, который специально подбирался под достаточность для
сборки тестового syslinux.iso.

Как и всё, что в /usr, его стоит воспринимать как read-only. :)

> > Вообще-то идея mkimage-profiles как раз в том, чтоб не
> > приходилось устраивать мульёны клонов _профиля_, а максимум
> > генерировать _заготовки_ для ручной допилки
> Эт если один раз поиграться с одним образом. 
> А если  работать с несколькими разными и параллельно и не один день ?

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

> > См. тж. http://www.altlinux.org/Mkimage/Profiles/m-p/howto
> Речь не про копирование всего m-p

А почему?

> а "вытаскивание" для последующего ковыряния конкретно того, что
> касается только одного образа. И что-бы эти "заготовки" можно
> было чётко идентифицировать, и дальше, когда будет отлажено
> точно, что нужно получить\изменить в них, тогда можно  отдавать
> для других.

Для этого можно make CHECK=1 syslinux.iso и скопировать себе
в сторонку полученный build/ (или иной BUILDDIR), но, как уже
отметил, это путь в никуда в долгосрочном плане, проверено.

Т.е. такой компактный генерат полезен для трёх задач:
- собственно сборка образа;
- вычитка _всего_ полностью (он обозрим);
- мелкие _одноразовые_ правки по месту.

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

http://webhamster.ru/mytetrashare/index/mtb0/13867044528tikz5mlg1

На производных стоит разве что тренироваться, ну или решать
точечные задачи, как в HOWTO-шке и описано...

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel-distro] о создании производных целей в m-p

[Leo-sp50]

> Как и всё, что в /usr, его стоит воспринимать как read-only. :)
>
О том и речь, что-бы использовать его по изначальному назначению (насколько помню историю m-p)
метапрофиль - это донор для создания конкретного профиля образ и все ковыряния\модернизации в 
полученном сборочном профиле. Или нет ?

>>  > Вообще-то идея mkimage-profiles как раз в том, чтоб не
>>  > приходилось устраивать мульёны клонов _профиля_, а максимум
>>  > генерировать _заготовки_ для ручной допилки
>>  Эт если один раз поиграться с одним образом.
>>  А если работать с несколькими разными и параллельно и не один день ?
>
> Для этого есть гитовые ветки. Потому что у этих "нескольких
> разных" нередко находятся общие доработки и держать в голове,
> какой кусок разницы откуда и для чего -- умаешься, а с гитом
> всё раскладывается по веткам и коммитам естественным образом.
>
У гита есть один недостаток - он не даёт доступа одномоментно к нескольким вариантам (веткам).
Как вариант примера : имеем три дистра, с профилями в отдельных каталогах, с разными архитерктурами ,  
с разными задачами и содержимым профилей. Пока идёт сборка одного дистра, можно
спокойно работать с другими профилями, править\эксперементировать\думать\пробовать  :)
Один общий гит это сможет ? 

>>  > См. тж. http://www.altlinux.org/Mkimage/Profiles/m-p/howto
>>  Речь не про копирование всего m-p
>
> А почему?
>
Не понял , что почему ?


> Для этого можно make CHECK=1 syslinux.iso и скопировать себе
> в сторонку полученный build/ (или иной BUILDDIR), но, как уже
> отметил, это путь в никуда в долгосрочном плане, проверено.
>
> Т.е. такой компактный генерат полезен для трёх задач:
> - собственно сборка образа;
> - вычитка _всего_ полностью (он обозрим);
> - мелкие _одноразовые_ правки по месту.
>
> Нет смысла такие заготовки далее идентифицировать, поскольку это
> производные. Изменится базовый профиль -- и в том, что из него
> генерируется, появится ещё что-нибудь полезное, но на перенос
> таких новинок в уже зафиксированный генерат придётся тратить
> время на ровном месте вместо того, чтоб сделать git rebase своих
> правок основного профиля из того состояния, поверх которого они
> были сделаны, на текущее. Ну, соотношение мяса с луком лучше
> регулировать до мясорубки, а не после :)
>
> http://webhamster.ru/mytetrashare/index/mtb0/13867044528tikz5mlg1
>
> На производных стоит разве что тренироваться, ну или решать
> точечные задачи, как в HOWTO-шке и описано...
>
Ну если брать долгосрочную перспективу, то все образы можно считать
"не_идентичными" после любых изменений метапрофиля, но это же
не повод ставить на них крест  :)

Re: [devel-distro] о создании производных целей в m-p

[Michael Shigorin]

On Thu, Jul 23, 2015 at 06:06:07PM +0300, Leo-sp50 wrote:
> метапрофиль - это донор для создания конкретного профиля образ
> и все ковыряния\модернизации в полученном сборочном профиле.
> Или нет ?

Одноразовые ковыряния можно делать и в полученном,
а долгоиграющие -- только в метапрофиле.  Ну, если
результат захочется смержить разумными усилиями.

> У гита есть один недостаток - он не даёт доступа одномоментно к
> нескольким вариантам (веткам).  Как вариант примера : имеем три
> дистра, с профилями в отдельных каталогах, с разными
> архитерктурами ,  с разными задачами и содержимым профилей.
> Пока идёт сборка одного дистра, можно спокойно работать с
> другими профилями, править\эксперементировать\думать\пробовать
> :) Один общий гит это сможет ? 

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

> >> > См. тж. http://www.altlinux.org/Mkimage/Profiles/m-p/howto
> >> Речь не про копирование всего m-p
> > А почему?
> Не понял , что почему ?

Там у тебя дальше по тексту было: "а "вытаскивание" для
последующего ковыряния конкретно того, что касается только
одного образа" -- я и говорю, что долгосрочно работать есть
смысл как раз по m-p, а не по генерируемым им сборочным профилям.

> > На производных стоит разве что тренироваться, ну или решать
> > точечные задачи, как в HOWTO-шке и описано...
> Ну если брать долгосрочную перспективу, то все образы можно
> считать "не_идентичными" после любых изменений метапрофиля,
> но это же не повод ставить на них крест  :)

Образы -- это вторая производная (первая -- сгенерированный
профиль); т.е. любые изменения в m-p могут привести к изменениям
в сгенерированном профиле, а даже при неизменном сгенерированном
профиле любые изменения в репозитории пакетов могут отразиться
на собранном по нему образе.

Порисуй себе на бумажке, что на что влияет. :)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info