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

[Axel Thimm]

On Wed, Sep 24, 2003 at 06:57:38AM -0400, Peter Bowen wrote:
> On Wed, 2003-09-24 at 03:45, Axel Thimm wrote:
> > 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.
> > 
> > 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 ...
> 
> First, I would encourage you, and anyone else doing something like this
> to strongly consider doing 'rpm -qf --qf "%{VERSION}"
> /etc/redhat-release', as checking for the redhat-release package will
> fail on RHEL.

Thanks for the tip. (I wouldn't like to put RHEL packages in the same
upgrade path line as rh/fc packages, so I would poll the version
explicitely from the corresponding rpm file and use a different
disttag alltogether like rhel3).

> Second, it shouldn't be a big deal to come up with a versioning scheme
> that will satisfy your needs.  Epochs are definitely not the answer. 
> Your best bet, if you require the new package to compare favorably
> -18.rh80 would be to do -18.1fc,

This would rather read 

     -18.1fc0.94

(or whatever the fc release might be). Adding the usual repo id tag,
you land at

    -18.1fc0.94.at

This my-release-tag-is-longer-than-your-release-tag madness must
stop. It will push repo maintainers to either drop upgrade paths, or
to come up with different versioning, e.g. rh10, to keep their repo
structure intakt.

> as that would be "newer" according to rpm.  Recent rpm versions
> always will sort a numeric character higher than an alphabetic
> character.

Which is also another problem with upgrade paths as the starting
release may have the toggling alphanumeric rpm bug (I think anything
<= rpm-4.1, so at least the whole 7.x series is affected - not that is
really makes sense to jump from 7.x to current rh/fc/rawhide).
-- 
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/20030924/4b470b5f/attachment-0002.bin