Bug 20912

Summary:	Implement instantiation of parameterized spec files with parameters defined by tags
Product:	Sisyphus	Reporter:	Alexander Bokovoy <ab>
Component:	gear	Assignee:	Dmitry V. Levin <ldv>
Status:	CLOSED FIXED	QA Contact:	qa-sisyphus
Severity:	enhancement
Priority:	P3	CC:	aen, anubix, erthad, glebfm, ktirf, ldv, legion, mike, ns, placeholder, vsu, zerg
Version:	unstable
Hardware:	all
OS:	Linux
Bug Depends on:
Bug Blocks:	26480

Description Alexander Bokovoy 2009-07-29 21:56:35 MSD

When multiple products are in the same branch and are built from separate spec files, it is currently impossible to specify which specfile to use for which product.

It would be good to add a spec-match: rule to gear rules that allows to extract specfile name from the tag that is used for build.

Suppose that tag is in specific format (altlinux-<name>-<version>). Something like this
git show-ref -d --tags |grep $main_tree_sha1|cut -d/ -f3|cut -d- -f2
would allow to extract <name> and use that as specfile name.

If spec-match would support a regular expression to replace the latter cut call, it would be a great enhancement.

Comment 1 Dmitry V. Levin 2009-08-18 21:13:52 MSD

(In reply to comment #0)
> When multiple products are in the same branch and are built from separate spec
> files, it is currently impossible to specify which specfile to use for which
> product.
> 
> It would be good to add a spec-match: rule to gear rules that allows to extract
> specfile name from the tag that is used for build.

That is, tag object used for build will provide additional information used for build, besides commit id?

Comment 2 Alexander Bokovoy 2009-08-18 23:55:08 MSD

For example, tag name could be used for that. Suppose I have multiple packages in the same git and branch, and would like to package them separately (this is the case with Samba code, for example). I'd like to have separate gear rules or separate spec files.

When I'd tag the object, I'd use tag's name to encode what I want to parse later in spec-match: rule to get the spec file name.

Comment 3 Dmitry V. Levin 2009-08-19 00:29:49 MSD

Good news: tag name is part of tag object, so it can be calculated from any tag name alias and cannot be changed without changing tag id.  For example,
gear$ git cat-file tag 1.5.3-alt1 |sed '/^tag /!d;s///;q'
1.5.3-alt1

Not so good news: with proposed feature implemented, commit id will no longer be always sufficient to build from.  From another side, in production environment (like girar-builder) gear is invoked only with tag objects anyway.

First gear versions was capable to build from tree id, now commit id is required.
I'm almost convinced that requiring tag id for some use cases is acceptable change.

What say ye?

Comment 4 Alexander Bokovoy 2009-08-19 08:08:06 MSD

From my point of view we anyway end up with tag objects in case we need tracked and proven build history. This, of course, ofsets "temporary commits" approach used in gear for some workflows but the gain is higher.

Comment 5 Dmitry V. Levin 2012-12-14 03:25:12 MSK

I'm slightly changing the subject to describe the idea which is being implemented.
It's essentially the same: tag object not only references to a commit object but also affects the way how its spec file is processed.

Comment 6 Repository Robot 2012-12-15 02:33:10 MSK

gear-2.0.0-alt1 -> sisyphus:

* Fri Dec 14 2012 Dmitry V. Levin <ldv@altlinux> 2.0.0-alt1
- gear-sh-functions (expand_rpm_macros): changed macros expansion
  algorithm to expand those macros that are known and leave unknown
  macros unexpanded.
- Implemented .gear/rules specsubst directive that controls
  instantiation of spec file templates with parameters
  defined by tag objects (closes: #20912).