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

[Peter Bowen <pzb datastacks com>]

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.

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, as that would be "newer" according to
rpm.  Recent rpm versions always will sort a numeric character higher
than an alphabetic character.

Thanks.
Peter