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.
(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?
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.
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?
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.
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.
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).
