Improve the way rpm decides what is newer

Christian Iseli Christian.Iseli at unil.ch
Fri Nov 20 23:58:05 UTC 2009


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.

I did not find a real easy way, but one way which does not seem too hard
to implement would be to introduce one additional tag in a package
named something like VendorRelease.  Then, given package A and B we
could implement the "what is newer" comparison as follows:
A.Vendor <=> B.Vendor
|| A.VendorRelease <=> B.VendorRelease
|| A.Epoch <=> B.Epoch
|| A.Version <=> B.Version
|| A.Release <=> B.Release

The VendorRelease, Epoch, Version and Release would be implemented
using the usual, current comparison method.  The Vendor comparison
would be taken from a config file, where the admin can decide what is
the preferred Vendor tag.

We might thus be able to solve the old dispute of having repotags by
punting it into the hands of the user.  If the user is happy to take
newer versioned packages from some third party repo, he can just define
both Vendors as equal in the config file.

This would also allow getting rid of Epochs from one Fedora release to
the next, since a newer VendorRelease would trump the non-null Epoch.

I'm a bit afraid this might degenerate into another flame fest, but
having slept on it I still think this idea has some merit.  So putting
on my asbestos underpants and waiting to see what will come out of
this...

Cheers,
					Christian




More information about the fedora-devel-list mailing list