Improve the way rpm decides what is newer

[Mike McGrath]

On Sat, 21 Nov 2009, Jesse Keating wrote:

>
>
> On Nov 21, 2009, at 1:38, drago01 <drago01 at gmail.com> wrote:
>
> > On Sat, Nov 21, 2009 at 3:17 AM, Adam Williamson <awilliam at redhat.com>
> > wrote:
> > > On Sat, 2009-11-21 at 00:58 +0100, Christian Iseli wrote:
> > > > Hi folks,
> > > >
> > > > I also got bitten by the "FC11 packages 'newer' than FC12" hickup, and
> > > > while going through the yum remove/add maneuver I pondered:
> > > > - is there ever a time when, while upgrading from Fedora n to Fedora
> > > >  n+1 I would expect a package .fcn to be kept instead of getting
> > > >  the .fcn+1 instance ?
> > > > My answer was: no
> > > >
> > > > So I wondered if there would be a simple way to make this happen
> > > > regardless of whether a maintainer blunders and gets things slightly
> > > > out of sync between the 2 or 3 current Fedora releases.
> > >
> > > To me, this is the wrong fix. The problem here isn't RPM's version
> > > comparison logic, which is perfectly sound. Instead of nerfing up RPM
> > > comparisons, which are already full of enough hidden mines, we should
> > > just improve Fedora's package versioning conventions so this doesn't
> > > happen, or at least happens less often.
> >
> > We should just use release epochs, people might hate them for whatever
> > reasons, but they would easily prevent such issues from happing.
> >
>
> Which sounds great until 3.0.1 goes out on f11 while 2.5 is out on f12. Really
> don't want to see that "upgrade" happen.
>

Epochs are nasty.  Can anyone think of any other mechanism they could use
with rpm?  I'm not talking about what rpm can do today, but any other
mechanism we could make rpm do tomorrow that could replace epoch?

	-Mike