Retain upgrade paths (was: /etc/redhat-release?)

[Axel Thimm]

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/20030924/0bd10430/attachment.sig>