Summary: | Возможность НЕ менять Release и spec-файл при сборке под любые бранчи | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Zerg <anubix> |
Component: | gear | Assignee: | Dmitry V. Levin <ldv> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | enhancement | ||
Priority: | P3 | CC: | ab, aen, cas, enp, glebfm, lav, ldv, legion, mike, placeholder, radik, rider, viy, zerg |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux | ||
URL: | http://lists.altlinux.org/pipermail/devel/2007-December/148447.html | ||
Bug Depends on: | 20912 | ||
Bug Blocks: |
Description
Zerg
2011-10-20 12:14:45 MSK
Вот и кака подоспела в качестве примера: 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.
Осталось только получить возможность собирать один и тот же тэг в более чем один бранч. Повесить отдельный баг? |