Improve the way rpm decides what is newer
Przemek Klosowski
przemek.klosowski at nist.gov
Tue Nov 24 19:59:20 UTC 2009
On 11/21/2009 11:50 AM, Michael Schwendt wrote:
> Given that Epoch can make an update go from a higher %{version} to a lower
> one (which even may be a completely normal scenario for upstream project
> splits), you can't avoid making Epoch the most-significant portion of RPM
> version comparison. One can only work around versioning scheme flaws until
> one runs into an unexpected problem where an Epoch is needed. Introduce
> an Epoch, and it must be considered in any other explicit references
> (Obsoletes'n'friends).
Essentially, these proposals can be seen as attempts to introduce a
2-dimensional ordering: on one hand, classifying packages by their
version number, and on the other hand by a distribution. Mathematically
this is impossible---it's a well-known mathematical fact that there's no
consistent ordering relation in a complex plane. Indeed, people came up
with use cases for both version number being more important and less
important than the distribution number.
I agree that this is a 'process' issue---packages should be ordered
simply by the underlying software version and release, and there should
be a distribution release QA step that simply makes sure that all
released packages from distro N+1 are newer than latest updates in distro N
More information about the fedora-devel-list
mailing list