Improve the way rpm decides what is newer

[Przemek Klosowski]

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