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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
