[Fedora-packaging] Update guidelines with packages from CVS

[Michael Schwendt]

On Sun, 15 May 2005 17:43:46 -0500, Tom 'spot' Callaway wrote:

> 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}

Why? 0.0 is not the expected version of the final/stable release. So a
"0." prefix in %release is not needed and doesn't make sense either.

Only if %version is at final version already and if you want to keep
non-numerical parts, like "rc" or "alpha", outside %version, you move them
into %release and use a prefix, so the final release can start at 1.

> 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.

This is a problem not limited to comparing stable releases with
snapshots. It's a pretty ordinary case. Assume you have:

  foo-1.0-1.fc3.i386.rpm (stable release)
  foo-1.0-2.20050514cvs.fc4.i386.rpm (post-release snapshot)

and then:

  foo-1.0-2.fc3.i386.rpm (first erratum)
* foo-1.0-3.fc3.i386.rpm (second erratum)

The one with '*' is newer than the .fc4 snapshot. Compare that with a .fc4
package, which has a cvs co diff applied as patch and is not marked as a
snapshot in %release:

  foo-1.0-1.fc3.i386.rpm (stable release)
  foo-1.0-2.fc4.i386.rpm (post-release cvs changes applied as patch)

  foo-1.0-2.fc3.i386.rpm (first erratum)
* foo-1.0-3.fc3.i386.rpm (second erratum)

If the .fc4 cvs snapshot doesn't need an update, you get the same
problems. Dist tags don't help in that case either. They only help for
updates applied to multiple distribution versions at once.

Whenever you bump %release only on an older branch, you increase the
likelihood that you violate the distribution upgrade path.

This can also happen if you have use an older cvs snapshot for FC3
and a recent one for FC4,

  foo-0.0-1.20040903cvs.fc3.i386.rpm
  foo-0.0-1.20050514cvs.fc4.i386.rpm

and if you need to fix a security bug in the old snapshot and you
can't upgrade to latest cvs co because build requirements are insufficient,
you run into %release conflicts again:

* foo-0.0-2.20040903cvs.fc3.i386.rpm
  foo-0.0-1.20050514cvs.fc4.i386.rpm

> 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.

Exactly. And you could never go back to an older stable release in case
you found major problems in the CVS changes. However:

  foo-1.0-3.20050114cvs.fc4.noarch.rpm
  foo-1.0-4.fc4.noarch.rpm (revert to last stable release as last resort)

> 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.

That is no silver bullet either. A second bugfix to the stable release,
and you would get into trouble again. Why not just increase release in the
context of all current packages?

fc3:
 foo-1.0-1.noarch.rpm (stable release)
 foo-1.0-1.2.noarch.rpm (bugfix to stable release)
 foo-1.0-1.3.noarch.rpm (security fix to stable release)

fc4:
 foo-1.0-2.20041225cvs.noarch.rpm (post-release cvs co)

Later for fc4:
 foo-1.0-3.20050301cvs.noarch.rpm (post-release cvs co)
 foo-1.0-4.20050514cvs.noarch.rpm (post-release cvs co)
 foo-1.0-5.20050514cvs.noarch.rpm (bugfix to post-release cvs co)

Won't solve conflicts magically either, return to "bump most
significant portion of %release with every package release, only reset
to 1 if %version is increased."  And if you need to bump %release only
for an older distribution, avoid that the most significant part would
be higher or equal than any package for a newer distribution. Extend
integer release values to floating-point as a last resort,
e.g.  1.fc3 < 1.2.fc3 < 1.3.fc3 < 2.20050514.fc4

Just like the versioning scheme for snapshots, the scheme for pre-releases
is only to avoid unnecessary epoch bumps. Mixed with dist tags, it can get
funny...