Fedora and Fedora Legacy package versioning schemes (was: Retain upgrade paths)

[Axel Thimm]

I am changing the subject to avoid loosing the context again. I am
also top posting, as the quoted part below is for reference only and
not a reply. I hope this longish post clarifies the problem and
stimulates more constructive discussions (no, the thread until now was
not constructive ;)

If you are a "Fedora Legacy" champion take your time please to get
through it. I hope the problem becomes more transparent that way, and
that a good solution is found before everything gets hit in stone
(e.g. November).

Thank you for your time!

The problem:
============

The aim is to have packages for Red Hat Linux and Fedora (Core) which
should be naturally (speak rpm-wise) upgradeable. For Red Hat's packages
from release to release this is ensured by

o Updated upstream versions
o Updated release tags due to different packaging or simply due to
  rebuilding for the current release
o Epoch bumping where the above is not possible, e.g. downgrading a
  buggy package.

When common errata were issued, either the packages were having
different upstream versions, or the errata was using an ad hoc method
for ensuring upgrade paths, usually with suffixes derived from the
distro version, like .7x, .80, .90, or .7, .8 and .9.

There was no policy on how to deal with it, as it was not really an
issue within RH.

The true trouble comes up, when you want to maintain the same package
for multiple different releases, e.g. RH7.3, RH8.0, RH9, FC/FDR 1 etc.

This is a common task in the "Fedora Legacy" subcomponent.

These packages will have the same upstream version and will (whenever
possible) be based on the same sources (same SourceN/PatchN/specfile).

This had been discussed on fedora.us half a year before. The viable
solutions that emerged were to have suffixes at the rpm release tag
that order the rpms according to the distro version, e.g.

      foo-1.2.3-4_rh7.3
      foo-1.2.3-4_rh8.0
      foo-1.2.3-4_rh9

There are variations on this scheme, like dropping "rh" or using 73,
80, 90 instead of 7.3, 8.0 and 9.

The current decision to rewind the distro release is breaking such
schemes, and "Fedora Legacy" like repos need a solution.

Defining the problem domain for Fedora Legacy:
==============================================

a) We need a versioning scheme that ensures upgradability without
   obfuscating too much the VR scheme.
b) It should be possible to use the same sources/patches/specfiles with
   macro controlled differences
c) It should work with older rpm versions, e.g. don't let rpm compare
   numbers with letters.

The easiest way to achieve a) and b) is to have

	    Release: 4_%{disttag}

in the specfile and let %{disttag} expand to values in the right
rpm-order for the given distributions.

A proposal on the fedora.us side is to allow rpm to compare "rh9"
versus "1", which under newer rpms will resolve as older, but which is
not the case for RH7.x (possibly even stock RH8.0, but I may be
mistaken). There are updated rpm rpms fixing this issue, but they are
neither available via RHN, nor can Fedora Legacy assume that those
rpms are available on the system to be upgraded.

Therefore it is far better to compare numbers only with rpm.

So we need a versioning scheme f that numerically sorts

 ... < f("7.3") < f("8.0") < f("9") < f("1") < ...

Possible solutions:
===================

a) Call _internally_ the next release ("Fedora [Core] 1") "RawHide 10"
   or "RawHide 9.1". It looks compatible with RH's policy and would
   allow for tags like "rh10" to complete the above scheme.

b) Drop upgradability withing Fedora Legacy from RHL to FC/FDR.

c) Drop upgradability from rpm < 4.1 and use kludgy "rhnumber" <
   "number" idiom.

d) Use tags with something larger than "rh", e.g. "tfp" ("The Fedora
   Project")

X) Your suggestion here.

It is important to have Red Hat's consent on any sollution, as well as
a common versioning scheme across repositories of different
maintainers to allow for properly formulating cross-repository
dependencies and having easy identification by end users.

Optional good-to-have semantics:
================================
o Use the same versioning for Fedora.

  It would be good to have a scheme applicable to both Fedora Legacy
  as well as Fedora (current release). That way Fedora releases could
  automatically become Fedora Legacy without rebuilding and
  re-versioning.

o Use the same versioning for RawHide/Betas.

  This would help building more often for RawHide. E.g. the following
  scheme could be used until now:

	 foo-1.2.3-4_rh8.0
	 foo-1.2.3-4_rh8.0.93 (beta)
	 foo-1.2.3-4_rh8.0.94.20030325 (rawhide)
	 foo-1.2.3-4_rh9 (release)

On Wed, Sep 24, 2003 at 10:45:45AM +0300, Axel Thimm wrote:
> On Tue, Sep 23, 2003 at 07:28:58PM -0400, Elliot Lee wrote:
> > On Wed, 24 Sep 2003, Axel Thimm wrote:
> > 
> > > What about the versioning? Will xxx-release continue to have
> > > rpm-monotonic larger VRs than the previous releases?
> > 
> > EpochVR yes, VR no.
> > 
> > The beta will have redhat-release-0.94-1 (epoch 1).
> 
> That is ugly in multiple ways. Leaving all other reasons for not
> using epochs aside, this will break all upgrade paths from embedded
> disttags like 7.3, 8.0 or 9. The logical conduction would be to have
> these repos also bump up epochs to ensure rpm upgradability or invent
> their own versioning.
> 
> Any way it will be creating confusion and disorder. ;)
> 
> Could a better mechanism be created before the 25th that enables
> disttags to be carried on? Please use no epoch/release, and make the
> version be (rpm-)bigger than "9". Also keep redhat-release as a proper
> package carrying that version information.
> 
> Background:
> ===========
> 
> Up to now RH was not often in the need to release multiple versions of
> the same package for different RH releases. Even if the package did
> not change its release tag was bumbed (rebuilt for xxx).
> 
> Errata were either based on different upstream sources, so no upgrade
> clashes could come up, while in the very rare cases, where exactly the
> same package was rebuilt for different RH release the package
> maintainer had to invent a scheme that worked in that timeframe
> (e.g. the kernel errata releases for RH 7.3/8.0/9).
> 
> 3rd party repos have been using the idiom of keeping the same upstream
> release current in multiple RH releases more often. The only portable
> way up to now to do so was to inspect the rpm-version value of
> redhat-release. Tags were created like
> 
> 	foo-fooversion-foorelease.rh8.0.i386.rpm
> 
> etc., ensuring sane upgrade paths for users of the 3rd party
> repo. Here are some google pointers:
> 
> http://www.google.com/search?q=rpm+%22--qf%22+version+redhat-release
> 
> My plea is therefore to
> 
> o keep redhat-release as a package of its own, so that
>   `rpm -q --qf "%{VERSION}" redhat-release' still works.
> o Make the version of this package rpm-monotonic without using epoch
>   (or even release tags), e.g. use a version rpm-larger than "9".
> o Put redhat-release into rawhide carrying the anaconda version ...
> 
> The alternative is to break the upgrade path mechanism of several
> repos or single package sites, please don't.



-- 
Axel.Thimm at physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031006/a858271e/attachment.sig>