On Sun, 04 Aug 2013 09:12:06 -0500 Rex Dieter rdieter@math.unl.edu wrote:

On 08/04/2013 07:14 AM, Darryl L. Pierce wrote:

...

There is at least one (likely more) scripts in use for doing mass rebuilds that are incorrectly bumping the release value. I noticed this before and brought it up in IRC but didn't file a bug then.

This is probably the rpmdev-bumpspec tool (from rpmdevtools).

it is.

kevin

On Sun, Aug 04, 2013 at 10:34:50PM +0200, Michael Schwendt wrote:

On Sun, 4 Aug 2013 08:14:17 -0400, Darryl L. Pierce wrote:

...

There is at least one (likely more) scripts in use for doing mass rebuilds that are incorrectly bumping the release value. I noticed this before and brought it up in IRC but didn't file a bug then.

What's going on is that the script is incrementing the release by 1 but is not rounding off the value. So, for example, from one package I maintain (perl-qpid_proton) I see the following in the %changelog:

The spec file is bad:

Release: 3.1%{?dist}

This is a non-standard release versioning scheme, and certainly the bumpspec script should not mess with that value beyond bumping the most-significant number.

I see on the package naming guidelines that this should be 3{?dist}.1. I'll fix that in my packages for their next release.

Odd is how the release value has been increased before:

...

• Mon Jul 22 2013 Petr Pisar - 0.4-2.1

• Perl 5.18 rebuild

• Mon Apr 1 2013 Darryl L. Pierce - 0.4-1.1

• Changed the qpid-proton dependency to qpid-proton-c.
• Changed the qpid-proton-devel dependency to qpid-proton-c-devel.

• Fri Mar 1 2013 Darryl L. Pierce - 0.4-1

• Rebased on Proton 0.4.

-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging

On Mon, 5 Aug 2013 10:26:35 -0400, Darryl L. Pierce wrote:

...

The scripts doing these mass rebuilds ought to be doing something lik:

release = floor(current_release + 1)

rather than just bumping by 1.

Filed BZ#993058

Hmm, I had hoped you would agree that the script should not mess with the release value. It already tries to cover Fedora's Package_Versioning guidelines, i.e. the 0.x pre-release scheme, for example. So, once you've fixed the Release in perl-qpid_proton, the script would bump as expected. The script has bumped thousands of packages before.

On which basis should the script know when to "round up" as you describe? The number (or whatever else, such as a snapshot date) at the right of the leading number of %{release} could be anything. It could be the packager's internal package revision number (e.g. "patch-level").

On Mon, 5 Aug 2013 14:33:35 -0400, Darryl L. Pierce wrote:

...

On which basis should the script know when to "round up" as you describe? The number (or whatever else, such as a snapshot date) at the right of the leading number of %{release} could be anything. It could be the packager's internal package revision number (e.g. "patch-level").

If it detects that the release is something like ##%{?dist}.## then it should drop the decimal place and increment the release number.

That's a different case than what has been done in perl-qpid_proton. But again, how should the script know whether to drop anything? And how much to drop? If there were an option, it would likely not be the default during mass-rebuilds, because one cannot rule out that it wouldn't break someone's "strange" release versioning scheme. In either case, a "clean up" recipe would be needed. Cleaning up a Release tag could involve dropping pieces anywhere. You wanted it to drop something left of %dist, minor release bumps are right of %dist.

In older branches you may not want to drop anything automatically, because the package may have seen a "minor release bump for old branches" before: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bump...

rpmdev-bumpspec can be given the -r (--rightmost) option to prefer a minor release bump.

$ grep Release test.spec Release: 4%{?dist}.1 $ rpmdev-bumpspec -r test.spec $ grep Releasec -r test.spec Release: 4%{?dist}.2

$ grep Release test.spec Release: 5%{?dist} $ rpmdev-bumpspec -r test.spec $ grep Release test.spec Release: 5%{?dist}.1

At the very left side, the most important thing is to bump "correctly", i.e. to recognise Fedora's 0. prefix for pre-releases. Dropping less significant portions of the release tag is something the packager could do eventually (e.g. during an upgrade).

There's even an option for introducing and bumping at the very right side:

$ grep Release test.spec Release: 6%{?dist} $ rpmdev-bumpspec -s try test.spec $ grep Release test.spec Release: 6%{?dist}.try1 $ rpmdev-bumpspec -s try test.spec $ grep Release test.spec Release: 6%{?dist}.try2