#164 Add note about {release} into "Release Tag" chapter of Guidelines
Closed: Invalid None Opened 11 years ago by vondruch.

Hello,

If you want to do some pre-release version of package and you use following version line for example:

Release: %{?prever:0.}3%{?prever:.%{prerpmver}}%{?dist}

the rpmdev-bumspec wrongly updates the Release to:

Release: %{?prever:0.}3%{?prever:.%{prerpmver}}%{?dist}.1

It would be nice to mention in "Release Tag" chapter [1] of naming guidelines, that rpmdev-bumspec supports in this case several variables [2], such as release or baserelease, so if you use:

%global release 3[[BR]]
Release: %{?prever:0.}%{release}%{?prever:.%{prerpmver}}%{?dist}

the release is updated correctly by this tool.

[1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Release_Tag [[BR]]
[2] https://fedorahosted.org/rpmdevtools/browser/rpmdev-bumpspec#L47


It seems like you may have identified a bug in rpmdev-bumpspec. Unfortunately, your proposed workaround isn't a very good practice, and we do not want to codify it in the guidelines. The method that rpmdev-bumpspec uses to update the Release (when it cannot determine the canonical integer in the Release field to increment) is valid, just not optimal.

We would encourage you to file a bugzilla against rpmdev-bumpspec, in the specific case of it not being able to identify and properly increment the canonical integer.

I opened upstream ticket [1]. Let's see what they tell about, what are technical constraints. I am asking, because RelEngs are using this tool during mass rebuild and due to it, it sometimes results in version mess.

May be the guidelines should say that except macros, there should be exactly one integer and rpmdev-bumpsec should be able to handle this scenario.

[1] https://fedorahosted.org/rpmdevtools/ticket/18

BTW mentioning this tool somewhere in guidelines would help to keep version bumps among packages more consistent IMO.

The full story is a different one here. The predecessor of rpmdev-bumpspec (bumpspecfile.py), which has been used for mass-rebuilds of Fedora Extras, has tried to handle several odd Release versioning schemes as found in spec files, because packagers are free to invent obscure Release tags using lots of macros. And a few packagers still do that even years later.
That's why some special macro definitions are recognized, but during the FE era, only a minority of spec files obfuscated the Release tag (statistics about had been published).

The script tries to recognize Fedora's pre-release versioning scheme, so it can bump it correctly. But it doesn't go as far as expanding macro-madness in an attempt at trying to understand which macro definition it may need to touch without introducing a mistake.

Release: %{?prever:0.}3%{?prever:.%{prerpmver}}%{?dist}

looks overly complicated, because would you ever have %prever defined without %prerpmver being defined, too? And more important, normally you would need to touch the '3' manually anyway in order to reset it whenever undefining %prever. Or else you would jump from 0.3 to 3. So, if you don't fear that you would forget switching from 0.X to X and vice versa when necessary, you could use

Release: 0.3%{?prever:.%{prerpmver}}%{?dist}

and rpmdev-bumpspec would understand how to handle that. Alternatively, you could use

{{{
%if 0%{!?prever:1}
Release: 3%{?dist}
%else
Release: 0.3%{?prever:.%{prerpmver}}%{?dist}
%endif
}}}

and unless there is a script that resets the Release value automatically for a version bump, you would still need to do that manually.

Or even

{{{
%if 0%{!?prever:1}
Release: 3%{?dist}
%else
Release: 0.3.%{prerpmver}%{?dist}
%endif
}}}

since %prerpmver will need to be defined for the pre-release scheme to make sense.

However, your macros don't allow for the post-release versioning scheme. I can't guess what your original macro-fied Release tag would look like for a packaged post-release snapshot.

Login to comment on this ticket.

Metadata