Вот и кака подоспела в качестве примера:
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.

Осталось только получить возможность собирать один и тот же тэг в более чем один бранч.

Повесить отдельный баг?