Не хватает более гибкой параметризации в .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'ы.
Приходится также "хардкодить" @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. ***
