Hi,
On Fri, Apr 09, 2004 at 10:07:06AM +0200, Enrico Scholz wrote:
> A yet more aggressive proposal would be
>
> | %{!?releasefunc:%define releasefunc() 0.fdr.%1}
> | Release: %releasefunc XYZ
ATrpms is using exactly that construct since a year now (releasefunc is
called atrelease here). It was introduced in the hope of finding a
common versioning scheme and not having to change the specfiles.
But there are problems (read severe bugs) with parameterized macros in
rpm (at least up to 4.2.1), which break this construct. Unfortunately
parameterized macros are not used often in rpm, so the chance of this
getting fixed is low.
I am contemplating to use (and suggest) the following simplified
scheme:
Release: <buildnumber>%{?releasesuffix}
(or a nicer name than releasesuffix, suggestions are welcome)
This macro should be externally given, and could therefore implement
different namings/versionings, while the standard user could still
rebuild the package resulting in a sane looking one even on non
Fedora/Red Hat worlds.
Even w/o having different repo maintainers agreeing on common
versioning the specfiles could become policy free and
repo/distribution portable that way.
"Tricks" wrt to version-shifting-to-release (pre, cvs etc. builds), or
second-hierachy builds (<vendortag>_<localtag>) belong to the
<buildnumber above>, while releasesuffix would typically be something
like [.%{disttag}.]%{repotag}, but that's up to the repo maintainers
to decide (e.g. current Red Hat policy would be to keep it empty and
so on).
We have discussed the above scheme a bit on the repo-coord list. Care
to join?
--
Axel.Thimm at ATrpms.net
Attachment:
pgp6OOIo9cv9r.pgp
Description: PGP signature
