On Tue, Jan 03, 2023 at 12:00:21PM +0100, Zdenek Dohnal wrote:
Hi all,
I would like to ask a question about whether the workflow below, which I use frequently, can be used in packages which uses rpmautospec. I hit this when I was doing a testing scratch build of another package which already switched to rpmautospec and since rpmautospec is now proposed to be default for new packages, I would like to know whether, and if so, how my workflow can be applied with rpmautospec.
My workflow:
If I have a fix which I want to send to user to verify in its environment, I do a testing build, which has the same release as the current stable package (f.e. 1.fc37), but I add additional suffix to set the testing build to higher NVR than the package in the stable (f.e. 1.fc37.test.1). Then the user can just install the testing packages via DNF, accepting koji links to RPMs, and once an official fixed package arrives (with bumped NVR - 2.fc37), the official stable package replaces the testing one, ensuring the user has the supported rpms.
Is this doable with rpmautospec and if it is, how?
My understanding — which may be not be the whole picture — is that this is not supported by rpmautospec natively. Essentially, every spec file change is _supposed_ to caused the Release number to grow, so by definition, a commit that adds a minorbump will also cause a bump of the release value, which is not useful.
The desired effect can be implemented by overriding %dist:
%global dist %dist~test.0 Release: %autorelease
Notice that I used '~' to make the redefined %dist _lower_ than the original. Let's say that the last official build had Release==1. When this spec is built, you end up with Release==2.fc38~test.0. When the %dist override is removed, and the package is built officially, we end up with Release==2.fc38 (2.fc38~test.0 < 2.fc38).
Zbyszek