Приходится также "хардкодить" @name@. Например, такая конструкция:
diff: @version@:@name@ @version@-@release@:@name@ name=@name@-@version@-alt.patch
Не проходит, приходится @name@ "хардкодить" :(

(In reply to comment #1)
> Приходится также "хардкодить" @name@. Например, такая конструкция:
> diff: @version@:@name@ @version@-@release@:@name@ name=@name@-@version@-alt.patch
> Не проходит, приходится @name@ "хардкодить" :(

Такая конструкция работает, если простой парсер spec-файла сможет вычислить name, version и release.

(In reply to comment #2)
> (In reply to comment #1)
> > Приходится также "хардкодить" @name@. Например, такая конструкция:
> > diff: @version@:@name@ @version@-@release@:@name@ name=@name@-@version@-alt.patch
> > Не проходит, приходится @name@ "хардкодить" :(
> 
> Такая конструкция работает, если простой парсер spec-файла сможет вычислить
> name, version и release.

version и release вычисляется.

$ gear --rpmbuild -- rpmbuild -bs
gear: .gear/rules line 2: tree "@name@" not found in "39504044ac7d005b23100c1d13c9358accf2e131"

$ grep '^Name:' v86d.spec
Name: v86d

Если заменить @name@ на явный v86d, то всё работает.

(In reply to comment #3)
> (In reply to comment #2)
> > Такая конструкция работает, если простой парсер spec-файла сможет вычислить
> > name, version и release.
> 
> version и release вычисляется.
> 
> $ gear --rpmbuild -- rpmbuild -bs
> gear: .gear/rules line 2: tree "@name@" not found in "39504044ac7d005b23100c1d13c9358accf2e131"
> 
> $ grep '^Name:' v86d.spec
> Name: v86d
> 
> Если заменить @name@ на явный v86d, то всё работает.

Дайте мне (ссылку на) репозиторий, в котором @name@ не раскрывается.
В любом случае нераскрываемость @name@ это отдельный вопрос.

(In reply to comment #4)
> Дайте мне (ссылку на) репозиторий, в котором @name@ не раскрывается.

http://git.altlinux.org/people/led/packages/v86d.test.git

> В любом случае нераскрываемость @name@ это отдельный вопрос.

Там ещё один ньюанс есть: если в спеке после
Name: foo
есть пробел, то @name@ не парсится

(In reply to comment #5)
> (In reply to comment #4)
> > Дайте мне (ссылку на) репозиторий, в котором @name@ не раскрывается.
> 
> http://git.altlinux.org/people/led/packages/v86d.test.git

Исправлено в
http://git.altlinux.org/people/ldv/packages/?p=gear.git
Если бы это было оформленно отдельным баг репортом, то я мог бы его закрыть.

> > В любом случае нераскрываемость @name@ это отдельный вопрос.
> 
> Там ещё один ньюанс есть: если в спеке после
> Name: foo
> есть пробел, то @name@ не парсится

Исправлено в
http://git.altlinux.org/people/ldv/packages/?p=gear.git
Если бы это было оформленно отдельным баг репортом, то я мог бы его закрыть.

Это всё не касается первоначального вопроса про более гибкую параметризацию в .gear-rules.

(In reply to comment #6)
> Это всё не касается первоначального вопроса про более гибкую
> параметризацию в .gear-rules.

Прошу прощения: я "повёлся" на (возможно) слишком общий Summary этого багрепорта.

(In reply to comment #7)
> (In reply to comment #6)
> > Это всё не касается первоначального вопроса про более гибкую
> > параметризацию в .gear-rules.
> 
> Прошу прощения: я "повёлся" на (возможно) слишком общий Summary этого багрепорта.

Fixed Summary. :)

Кроме того у меня встречались задачи, когда хотелось бы определять переменные параметрами при запуске gear, и раскрывать их как в gear-rules, так и в spec-файле

(In reply to comment #9)
> Кроме того у меня встречались задачи, когда хотелось бы определять
> переменные параметрами при запуске gear, и раскрывать их как в gear-rules, так и в
> spec-файле

Хоть это и не противоречит условию воспроизводимости сборки в gear, но сильно её затруднит.

(In reply to comment #10)
> Хоть это и не противоречит условию воспроизводимости сборки в gear, но сильно
> её затруднит.
Ну я не настаиваю на таком улучшении. Просто для внутреннего использования (не для отправки в sisyphus) есть такая задача. Вообще я встречал пожелание уметь кастомизировать spec перед отправкой в hasher. В частности так можно резать большой spec на куски, и собирать их вместе, ну и вообще препроцессить.

Естейтсвенно, что в репозитарий уместно принимать только чистые спеки. Но для частных задач такие возможности могли бы пригодиться.

*** Bug 21273 has been marked as a duplicate of this bug. ***