Bug 12387

Summary: [FR] Нужна более гибкая параметризация в .gear/rules
Product: Sisyphus Reporter: at <at>
Component: gearAssignee: Dmitry V. Levin <ldv>
Status: NEW --- QA Contact: qa-sisyphus
Severity: enhancement    
Priority: P2 CC: asy, erthad, glebfm, ldv, led, legion, mike, placeholder, rlz, vvk
Version: unstable   
Hardware: all   
OS: Linux   

Description at@altlinux.org 2007-07-20 18:47:46 MSD
Не хватает более гибкой параметризации в .gear-rules.  Единственными
параметрами, о которых идет речь, являются @version@ и @release@.  Чтобы делать
сборки на основе svn-snapshot'ов с "оригинальным" тарболлом, приходится
хардкодить ещё один параметр (условно @snapshot@) прямо в .gear-rules.  Это
сводит на нет пользу от параметризации.

Другим проблемным случаем является видоизмененная версия пакета.  Например,
тарболл имеет версию 0.2808, а пакет -- 0.28.08 ("выравнивание" версий для
rpmvercmp).

http://lists.altlinux.org/pipermail/devel/2007-July/048442.html
http://lists.altlinux.org/pipermail/devel/2007-July/048412.html

Нужен рекомендуемый вариант для сборки пакетов из snapshot'ов (в частности, из
импортированных репозитариев).  Иначе я не знаю, как их собирать!  А то малявы
будут писать а виноват буду я.

С другой стороны, все эти рассуждения возникают из желания сохранить старую и
более привычную структуру src.rpm.  Меня устраивает %name-%version-%release.tar,
но это не устраивает других, пока будут публиковаться src.rpm'ы.
Comment 1 led 2008-10-06 20:38:42 MSD
Приходится также "хардкодить" @name@. Например, такая конструкция:
diff: @version@:@name@ @version@-@release@:@name@ name=@name@-@version@-alt.patch
Не проходит, приходится @name@ "хардкодить" :(
Comment 2 Dmitry V. Levin 2008-10-06 20:49:47 MSD
(In reply to comment #1)
> Приходится также "хардкодить" @name@. Например, такая конструкция:
> diff: @version@:@name@ @version@-@release@:@name@ name=@name@-@version@-alt.patch
> Не проходит, приходится @name@ "хардкодить" :(

Такая конструкция работает, если простой парсер spec-файла сможет вычислить name, version и release.
Comment 3 led 2008-10-06 21:02:43 MSD
(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, то всё работает.
Comment 4 Dmitry V. Levin 2008-10-06 21:13:53 MSD
(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@ это отдельный вопрос.
Comment 5 led 2008-10-09 13:01:56 MSD
(In reply to comment #4)
> Дайте мне (ссылку на) репозиторий, в котором @name@ не раскрывается.

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

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

Там ещё один ньюанс есть: если в спеке после
Name: foo
есть пробел, то @name@ не парсится
Comment 6 Dmitry V. Levin 2008-10-09 14:30:41 MSD
(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.
Comment 7 led 2008-10-09 14:36:53 MSD
(In reply to comment #6)
> Это всё не касается первоначального вопроса про более гибкую
> параметризацию в .gear-rules.

Прошу прощения: я "повёлся" на (возможно) слишком общий Summary этого багрепорта.
Comment 8 Dmitry V. Levin 2008-10-09 14:38:48 MSD
(In reply to comment #7)
> (In reply to comment #6)
> > Это всё не касается первоначального вопроса про более гибкую
> > параметризацию в .gear-rules.
> 
> Прошу прощения: я "повёлся" на (возможно) слишком общий Summary этого багрепорта.

Fixed Summary. :)
Comment 9 rlz 2008-11-27 19:58:10 MSK
Кроме того у меня встречались задачи, когда хотелось бы определять переменные параметрами при запуске gear, и раскрывать их как в gear-rules, так и в spec-файле
Comment 10 Alexey Gladkov 2008-11-27 20:06:47 MSK
(In reply to comment #9)
> Кроме того у меня встречались задачи, когда хотелось бы определять
> переменные параметрами при запуске gear, и раскрывать их как в gear-rules, так и в
> spec-файле

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

Естейтсвенно, что в репозитарий уместно принимать только чистые спеки. Но для частных задач такие возможности могли бы пригодиться.
Comment 12 Dmitry V. Levin 2010-06-01 23:39:37 MSD
*** Bug 21273 has been marked as a duplicate of this bug. ***