bad use of "Dist Tag" in some packages of rawhide

[Michael Schwendt]

On Sat, 02 Nov 2013 22:11:19 +0100, Xose Vazquez Perez wrote:

> > On Sat, 02 Nov 2013 19:39:38 +0100, Xose Vazquez Perez wrote:
> 
> >> _rawhide_ is not an *old branch* . And it never was.
> >> 
> >> To have {?dist}.X in rawhide should be impossible.
> >> 
> >> It breaks the laws of thermodynamics!!
> > 
> > It looks ugly, but it's harmless.
> 
> Harmless or not, but it breaks the Fedora policy.

That would be an overly pedantic interpretation of the guidelines.
Nothing forbids N.%{?dist}.X in Rawhide. Bumping N is preferred, of
course, but since Rawhide is supposed to contain the "latest" (i.e.
package with the highest EVR) anyway, rebuild attempts or bug-fix
attempts could bump X at the end. And, (again) of course, the packager
ought to get rid of that appended stuff eventually.

You need to understand that "Minor_release_bumps_for_old_branches" are
also applied by the rpmdev-bumpspec script as a valid fallback, if no
release versioning scheme is recognised in a spec file (e.g. because of
macro-madness) during a mass-rebuild for Rawhide. If you want that script
to not increase the least-significant part of the Release tag, further
development of it will be needed. Perhaps with a completely different
approach that would evaluate the %release value and rewrite the Release
tag from scratch if necessary, deleting macro-madness, annoying some
packagers. ;)

  $ rpm -q kernel
  kernel-3.12.0-0.rc7.git0.1.fc21.x86_64
  kernel-3.12.0-0.rc7.git1.2.fc21.x86_64
  kernel-3.12.0-0.rc7.git2.2.fc21.x86_64

Apparently, not even the kernel package applies Fedora's official
pre-release snapshot release scheme. It would need to be a combination
of these two:
  https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages
  https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages

It isn't easy to get all package maintainers to use simple release
versioning schemes, throwing away the flexibility they want. As you've
found out in the opening post of this thread already, there are packages
that don't adhere to the guidelines. The guidelines are quite complex
with regard to post/pre-release snapshots from SCM systems. Some packagers
don't violate the upgrade path, if they apply their own working scheme.
Others get it wrong, if they are forced to follow lengthy guidelines.