ms-nospam-0306@xxxxxxxx (Michael Schwendt) writes:
>> Note: If you are building packages for fedora.us, you should not
>> manually add a %{disttag} to the spec files.
>
> Actually there's a difference between adding a macro like %{disttag}
> which would be undefined by default and could be set like
>
> rpmbuild --rebuild --define "disttag .rh80" foo.src.rpm
>
> and hard-coding a disttag in the "Release:" field. ;o)
Well, a common sense regarding disttags would be really useful. The
buildsystem does some heuristics (regexp's) to replace/set the
correct disttag. I do not have a good feeling on this practice
since it can/will break on semi-intelligent disttag determination
algorithms, or on subpackages with different releases.
My suggestion would be to find a common macro-name for the disttag and
to use:
| Release: 0.fdr.XYZ%{?disttag}
in every .spec file. %disttag will be defined on a per buildroot base.
A yet more aggressive proposal would be
| %{!?releasefunc:%define releasefunc() 0.fdr.%1}
| Release: %releasefunc XYZ
This *two* lines must be in every .spec file. This would make it easy to
put a package into different repositories. E.g. livna.org could add the
'0.liv' prefix without changing the specfile.
It would ease to naming rules too, since finding of XYZ must be specified
only, but not its placement.
Drawbacks of this variant are the additional '%{!...}' line, and that is
does not work on RH <=8.0. But RH 8.0 is dead and packages in legacy are
limited so that manual specfile editing should not be a problem.
Both variants (%disttag and %releasefunc) can be used mixed in the
repository; it would be easy for the buildsystem to determine which one
is used.
Enrico
