For automatic rebuilds, mass changes, etc., rpmdev-bumpspec is used to increase the release number. This works nicely for packages that have a simple Release tag, for example 42%{?dist} gets bumped to 43%{?dist}.
rpmdev-bumpspec
Release
42%{?dist}
43%{?dist}
Some packages use complex Release tags with lots of macro calls; rpmdev-bumpspec cannot do anything sensible there, so it appends a .1. This leads to untidy looking results and extra work for human packagers removing that .1 again for their next manual release.
.1
However, rpmdev-bumpspec also has a solution for this problem: If a macro %baserelease (or %release) is defined by %define baserelease or %global baserelease prior to the Release tag, it will increment that macro's definition and leave the Release tag as is (https://pagure.io/rpmdevtools/blob/main/f/rpmdev-bumpspec#_45).
%baserelease
%release
%define baserelease
%global baserelease
For consistency, it would be very nice to require all packages that have Release tags that are not natively bumpable by rpmdev-bumpspec to define a %baserelease macro that can be safely and easily bumped by automatic processes and mass changers.
A lint-like test for this would be running rpm -q --specfile --define 'dist %{nil}' '--qf=%|epoch?{%{epoch}:}:{}|%{version}-%{release}\n' $specfile | head -1 and storing the result, running rpmdev-bumpspec $specfile, running rpm -q --specfile --define 'dist %{nil}' '--qf=%|epoch?{%{epoch}:}:{}|%{version}-%{release}\n' $specfile | head -1 again and ensuring that the post-bump result is different from the concatenation of the pre-bump result and .1.
rpm -q --specfile --define 'dist %{nil}' '--qf=%|epoch?{%{epoch}:}:{}|%{version}-%{release}\n' $specfile | head -1
rpmdev-bumpspec $specfile
(Technically, %define release or %global release should also work for rpmdev-bumpspec, but defining a macro with the same name as a tag feels like encouraging more confusion.)
%define release
%global release
In general, I think this is a good idea. If rpmdev-bumpspec can't bump Release correctly, a human probably won't be able to either. With Tilde and Caret based Versioning, this will become better, but people will always use nonstandard Version and Release tags, and having those handled by rpmdev-bumpspec correctly anyway would be nice.
Note, however, that at least as of the last version of the caret versioning scheme I had put forward, the Release: tag became quite simple even for a large majority of the packages that previously needed a complicated one. So it might be worthwhile to see if this is still needed after that goes through (assuming it will) and then work any required changes into the updated document.
Of course, and every package will be converted to the new versioning scheme on day one, and we'll all be happy ...
I assume that that's not going to be the case, and that there'll be still be packages that use weird schemes that using %baserelease could help with.
Just to clarify, my goal is less to push %baserelease, but more to make rpmdev-bumpspec work sensibly on all spec files. At the moment, in many cases the latter will require the former. If there are other ways to reliably achieve that, that would work for me. (Therefore an automatic lint warning/error would probably be useful.)
FWIW, packages should be using %autorelease nowadays…
%autorelease
I think we should focus on advertising that one instead of trying to fix somewhat hackish design. That said, I realized we don't have %auto* stuff anywhere on the guidelines ⇒ I'll open some follow-up.
Login to comment on this ticket.