Improve the way rpm decides what is newer

[Michael Schwendt]

On Sat, 21 Nov 2009 12:40:45 +0100, drago01 wrote:

> > On Sat, 21 Nov 2009 10:38:35 +0100, drago01 wrote:
> >
> >> We should just use release epochs, people might hate them for whatever
> >> reasons, but they would easily prevent such issues from happing.
> >
> > Vendor Epochs have been discussed years ago and have been rejected.
> > The normal %{epoch} in RPM Version Comparison is hidden and bad enough
> > already. We don't need another hidden "super-Epoch" that wins
> > version comparison even with that other %epoch.
> 
> You misunderstood me, I was not suggesting adding another epoch but
> simply bump the %{epoch}  for every release.

Okay, but the effect would not be different. You could only bump
%epoch for every released build of a package and/or inbetween releases
of the dist. In case of the latter, there would be a conflict with
ordinary bumps of %epoch in situations where you can't avoid that.
For the former, it reminds me of "Serial: %(date +'%Y%m%d')" in
hylafax upstream src.rpm once more, which was kind of a super-Epoch.

And in either case, it would get really ugly as we already need to
be careful with Epoch bumps that must be reflected in any explicit
Requires/Obsoletes/Conflicts in other packages.

We are glad that most packages don't set %epoch or don't change it often
if it's set already. Or else we would have continued with the old
explicit "Epoch: 0" rule from fedora.us instead of removing it from
packages in Fedora Extras.