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?
Thank you in advance!
Zdenek
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
On 1/3/23 12:19, Zbigniew Jędrzejewski-Szmek wrote:
Is this doable with rpmautospec and if it is, how?
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).
Thanks, Zbyszek! That's exactly I was looking for.
Zdenek
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, Jan 03, 2023 at 12:00:21PM +0100, Zdenek Dohnal wrote:
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).
While this is nice, note that it will work once only, i.e. you cannot do a test.1 against the same "-2" this way. Have you tried `-b` and `-e` options to `%autorelease`?
-
Michael J Gruber -
Zbigniew Jędrzejewski-Szmek -
Zdenek Dohnal