rpmautospec - how to add suffix to the current release and don't bump it right now

[Zdenek Dohnal]

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

-- 
Zdenek Dohnal
Software Engineer
Red Hat, BRQ-TPBC

[Zbigniew Jędrzejewski-Szmek]

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

[Zdenek Dohnal]

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- 
Zdenek Dohnal
Software Engineer
Red Hat, BRQ-TPBC

[Michael J Gruber]

>  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`?