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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
