12387 2007-07-20 18:47:46 +0400 [FR] Нужна более гибкая параметризация в .gear/rules 2010-12-28 00:03:58 +0300 1 1 4 Development Sisyphus gear unstable all Linux NEW P2 enhancement --- 1 at ldv asy erthad glebfm ldv led legion mike placeholder rlz vvk qa-sisyphus oldest_to_newest 53163 0 at 2007-07-20 18:47:46 +0400 Не хватает более гибкой параметризации в .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'ы. 79260 1 led 2008-10-06 20:38:42 +0400 Приходится также "хардкодить" @name@. Например, такая конструкция: diff: @version@:@name@ @version@-@release@:@name@ name=@name@-@version@-alt.patch Не проходит, приходится @name@ "хардкодить" :( 79263 2 ldv 2008-10-06 20:49:47 +0400 (In reply to comment #1) > Приходится также "хардкодить" @name@. Например, такая конструкция: > diff: @version@:@name@ @version@-@release@:@name@ name=@name@-@version@-alt.patch > Не проходит, приходится @name@ "хардкодить" :( Такая конструкция работает, если простой парсер spec-файла сможет вычислить name, version и release. 79266 3 led 2008-10-06 21:02:43 +0400 (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, то всё работает. 79267 4 ldv 2008-10-06 21:13:53 +0400 (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@ это отдельный вопрос. 79377 5 led 2008-10-09 13:01:56 +0400 (In reply to comment #4) > Дайте мне (ссылку на) репозиторий, в котором @name@ не раскрывается. http://git.altlinux.org/people/led/packages/v86d.test.git > В любом случае нераскрываемость @name@ это отдельный вопрос. Там ещё один ньюанс есть: если в спеке после Name: foo есть пробел, то @name@ не парсится 79386 6 ldv 2008-10-09 14:30:41 +0400 (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. 79387 7 led 2008-10-09 14:36:53 +0400 (In reply to comment #6) > Это всё не касается первоначального вопроса про более гибкую > параметризацию в .gear-rules. Прошу прощения: я "повёлся" на (возможно) слишком общий Summary этого багрепорта. 79388 8 ldv 2008-10-09 14:38:48 +0400 (In reply to comment #7) > (In reply to comment #6) > > Это всё не касается первоначального вопроса про более гибкую > > параметризацию в .gear-rules. > > Прошу прощения: я "повёлся" на (возможно) слишком общий Summary этого багрепорта. Fixed Summary. :) 81848 9 rlz 2008-11-27 19:58:10 +0300 Кроме того у меня встречались задачи, когда хотелось бы определять переменные параметрами при запуске gear, и раскрывать их как в gear-rules, так и в spec-файле 81849 10 legion 2008-11-27 20:06:47 +0300 (In reply to comment #9) > Кроме того у меня встречались задачи, когда хотелось бы определять > переменные параметрами при запуске gear, и раскрывать их как в gear-rules, так и в > spec-файле Хоть это и не противоречит условию воспроизводимости сборки в gear, но сильно её затруднит. 81850 11 rlz 2008-11-27 20:34:37 +0300 (In reply to comment #10) > Хоть это и не противоречит условию воспроизводимости сборки в gear, но сильно > её затруднит. Ну я не настаиваю на таком улучшении. Просто для внутреннего использования (не для отправки в sisyphus) есть такая задача. Вообще я встречал пожелание уметь кастомизировать spec перед отправкой в hasher. В частности так можно резать большой spec на куски, и собирать их вместе, ну и вообще препроцессить. Естейтсвенно, что в репозитарий уместно принимать только чистые спеки. Но для частных задач такие возможности могли бы пригодиться. 109626 12 ldv 2010-06-01 23:39:37 +0400 *** Bug 21273 has been marked as a duplicate of this bug. ***