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