Bug 12387 - [FR] Нужна более гибкая параметризация в .gear/rules
: [FR] Нужна более гибкая параметризация в .gear/rules
Status: NEW
: Sisyphus
(All bugs in Sisyphus/gear)
: unstable
: all Linux
: P2 enhancement
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2007-07-20 18:47 by
Modified: 2010-12-28 00:03 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-07-20 18:47:46
Не хватает более гибкой параметризации в .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 From 2008-10-06 20:38:42 -------
Приходится также "хардкодить" @name@. Например, такая конструкция:
diff: @version@:@name@ @version@-@release@:@name@
name=@name@-@version@-alt.patch
Не проходит, приходится @name@ "хардкодить" :(
------- Comment #2 From 2008-10-06 20:49:47 -------
(In reply to comment #1)
> Приходится также "хардкодить" @name@. Например, такая конструкция:
> diff: @version@:@name@ @version@-@release@:@name@ name=@name@-@version@-alt.patch
> Не проходит, приходится @name@ "хардкодить" :(

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

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

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

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

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

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

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

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