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

[Axel Thimm]

On Wed, Sep 24, 2003 at 04:34:50PM -0400, Bill Nottingham wrote:
> Axel Thimm (Axel.Thimm at physik.fu-berlin.de) said: 
> > > It's a new release model, hence a new release number. Fedora Core 10
> > > doesn't make sense.
> > 
> > It does, if you want to retain upgrade paths ...
> 
> What do you mean by 'upgrade paths'? All packages provided in the
> release, sort newer-or-equal, in the method used by all sane upgrade
> tools (E:V-R).  So, I don't see how we're not retaining an upgrade
> path.

This has not to do with fc isolated, but with the supporting 3rd party
repos. It was discussed further up this thread, but I will rephrase
with an example. There exist more than one repository building rpms
for several RH releases (say RH7.3, 8.0 and 9). In order to ensure
upgrade paths for the users of this repository the packages are being
called

     foo-1.2.3-1.rh7.3.i386.rpm
     foo-1.2.3-1.rh8.0.i386.rpm
     foo-1.2.3-1.rh9.i386.rpm

or similar variations like omitting the "rh" etc. Upgrades from one RH
release with enabled repo to another were thus safe.

Just to give more food for thought: How would you version a kernel
based on the same sources released for RH 7.x,8.0,9 and now
additionally fc?

	kernel-2.4.22-1.2082.7.i686.rpm
	kernel-2.4.22-1.2082.8.i686.rpm
	kernel-2.4.22-1.2082.9.i686.rpm
	kernel-2.4.22-1.2082.0.94.i686.rpm

The latter looses. You either have to rethink the first three or
version the last with something rpm-higher than "9". Or start epochin
all such packages occuring on multiple releases, which for somerpeos
means all of the carried packages.

You cannot save the above scheme with epochs. See the previous
messages in the thread with the "Background" information to see why
this didn't hit RH so often in the past, but possibly will do yo
rather often with shorter release cycles.

Or one decides to not support upgrade from older RH releases
concerning non-RH repos, which would be unfortunate.
-- 
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://lists.fedoraproject.org/pipermail/devel/attachments/20030925/969e861f/attachment-0002.bin