Было бы здорово иметь возможность в spec-файле писать что-то типа Release: %{gear_release alt1} , что будет автоматически вычисляться в необходимое значение для той ветки, под которую идет сборка.
Вот и кака подоспела в качестве примера: http://git.altlinux.org/tasks/56861/logs/events.4.1.log
Хотя, нет, это был не пример. Но смысл, думаю, понятен: вместо того, чтоб тупо отправить на сборку (реально для task 56861 потребовалось только 1-о исправление) мне пришлось изменять spec-и, подписывать tag-и и делать push для 56 пакетов.
(В ответ на комментарий №1) > http://git.altlinux.org/tasks/56861/logs/events.4.1.log В этом случае спасибо за check-git-inheritance! Как раз во время.
(В ответ на комментарий №2) > пришлось изменять spec-и, подписывать tag-и и делать push для 56 пакетов. Даже больше. Еще все новые пакеты в p6, которые я (и не только) отправил в рамках подготовки к KDE-4.7 после выхода KDesktop-6.0 для уменьшения кол-ва подзадач.
Поддерживаю. Было бы реально удобно.
Это продумывалось ещё в районе 2003 на примере apache.spec мной и позже на ещё чём-то raorn@ (может откопаться по словам release tag); вот формальный документ в исполнении ab@: http://lists.altlinux.org/pipermail/devel/2007-December/148447.html
(В ответ на комментарий №6) > Это продумывалось ещё в районе 2003 Если не напоминать, успешно забудется ;-)
Кстати, у SuSE вроде, исчез chnagelog из spec-файлов, стал отдельно. Может, и нам пригодиться какой-нибудь .gear/changelog
> Depends: bug 20912 Т.е. если нельзя будет сделать симлинк, меня не устроит.
(In reply to comment #9) > > Depends: bug 20912 Там описан транспорт (git tag object) для потенциального интерфейса выбора. Сам интерфейс выбора может быть каким угодно, хоть "X-gear: name value". Напрашивается keyword substitution @gear_name@ -> value в .gear/rules, rpmbuild --define "gear_name $value" во время сборки, но дальше полный туман. Что в этой ситуации делать с тэгом Release, несоответствием между %release и %changelog, и подстановкой @release@ -> %release, пока не ясно. > Т.е. если нельзя будет сделать симлинк, меня не устроит. Какой симлинк?
(В ответ на комментарий №10) > Что в этой ситуации делать с тэгом Release, несоответствием между > %release и %changelog, Переделать проверку, чтоб для Release %{gear_release alt1} и были валидны ченжлоги от alt0.M00A.1 до alt1 > и подстановкой @release@ -> %release, пока не ясно. Release %{gear_release alt1} -- alt1, чтоб не прыгало. > > Т.е. если нельзя будет сделать симлинк, меня не устроит. > Какой симлинк? Симлинк на "separate spec files", если они станут необходимы.
(В ответ на комментарий №11) > > и подстановкой @release@ -> %release, пока не ясно. > Release %{gear_release alt1} -- alt1, чтоб не прыгало. Или сделать @release@ и @gear_release@
Мне кажется, что необходимое значение релиза должно выставляться на стороне отправляющего и сохраняться у него в репозитории. В etersoft-build-utils, например, есть $ rpmbph -b p6 -u которая бэкпортирует спек, устанавливает нужный релиз и отправляет на сборку. А так получается, что мы хотим сделать неявный бэкпорт: ничего не меняя в пакете, отправить его на сборку. В ряде случаев из-за несовместимости веток это и не получится...
(В ответ на комментарий №13) > В ряде случаев из-за несовместимости веток это > и не получится... Волшебства никто и не предполагает. При правильно подготовленном заранее spec-файле получиться для всех веток, на которые рассчитано.
gear >= 2.0.0 позволяет с помощью тэгов выполнять достаточно произвольные подстановки в спеках.
Дима, а можно поподробнее ?
И можно ли переложить новый gear в t6/p6 ?
(В ответ на комментарий №15) > gear >= 2.0.0 позволяет с помощью тэгов выполнять достаточно произвольные > подстановки в спеках. А gear-create-tag ?
(В ответ на комментарий №17) > И можно ли переложить новый gear в t6/p6 ? Переложил. Ночью появится и в t6.
Осталось только получить возможность собирать один и тот же тэг в более чем один бранч. Повесить отдельный баг?
