[Fedora-packaging] Update guidelines with packages from CVS

[Tom 'spot' Callaway]

On Sun, 2005-05-15 at 22:52 +0200, Michael Schwendt wrote:

> > So, under current guidelines, that would basically mean:
> > 
> > # cvsdate should be in the format YYYYMMDD
> > %define cvsdate 20050515
> > # 0.0 is used for applications that do not have a proper version number.
> > Version: 0.0
> > # Increment first digit of release if making a change without new source
> > # checkout, if new source checkout, reset to 1.
> > Release: 1.%cvsdate%{?dist}
> > 
> > Does that seem reasonable?
> 
> Yes, IMO.
> 
> For snapshots of software with a previous release, i.e. with a real %
> version, the string "cvs" or "svn" after cvsdate in the release field
> would make it more clear that it's a post-release snapshot.

This is ok, its a logical extension of the "Non-Numeric Version in
Release" in PackageNamingGuidelines. We should come up with standardized
naming for the common version control systems ("cvs", "svn", "bk",
"git", "arch"). If there are no objections, I'll just use the ones in
the previous line. :)

Of course, this raises a few more issues:

Strictly speaking, as this falls under the "Non-Numeric Version in
Release" case, we should have a preceeding 0.

This changes the example case to:

# cvsdate should be in the format YYYYMMDD
%define cvsdate 20050515
# 0.0 is used for applications that do not have a proper version number.
Version: 0.0
# When the checkout is for a "pre-release", prepend with "0." 
# The build digit starts at 1, and increments if making a change 
# without new source checkout. If there is a new source checkout, reset
# the second digit to 1.
Release: 0.1.%{cvsdate}cvs%{?dist}

foo-0.0-0.1.20041225cvs.noarch.rpm (pre-release cvs co)
foo-1.0-1.noarch.rpm (stable release)
foo-1.0-2.noarch.rpm (bugfix to stable release)
foo-1.0-1.20050514cvs.noarch.rpm (post-release cvs co)

The problem is that 1.20050514cvs < 2, when it should be considered as
greater.

One possible workaround would be to increment the version number. 

With this, we'd have:
foo-0.0-0.1.20041225cvs.noarch.rpm (pre-release cvs co)
foo-1.0-1.noarch.rpm (stable release)
foo-1.0-2.noarch.rpm (bugfix to stable release)
foo-1.1-1.20050514cvs.noarch.rpm (post-release cvs co)
foo-1.1-2.20050514cvs.noarch.rpm (bugfix to post-release cvs co)

The problem with this solution is that we're relying on the psychic
abilities of the packager to guess the next release version. For some
packages, this may be possible (they bump version number early in the
source), but its a risky bet, since they could just as easily call the
next release 1.01. Then we have to use Epoch, and the end user remains
confused as to how foo-1.1 < foo-1.01. 

Another workaround would be to use the value of the highest %{release}
number from the stable release as the new "build digit".

With this, we'd have:
foo-0.0-0.1.20041225cvs.noarch.rpm (pre-release cvs co)
foo-1.0-1.noarch.rpm (stable release)
foo-1.0-2.noarch.rpm (bugfix to stable release)
foo-1.0-2.20050514cvs.noarch.rpm (post-release cvs co)
foo-1.0-3.20050514cvs.noarch.rpm (bugfix to post-release cvs co)

I'm inclined to document the latter option as the standard, but I'm open
to advice/alternatives here.

~spot
-- 
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!