[Rpm-maint] [rpm-software-management/rpm] version comparison with epoch does not work as expected (#450)

[Jeff Johnson]

@svpv: good for ROSA, and conversations with me might be partly responsible for the choice. Using the same epoch when one value is missing has the distinct advantages (aka "epoch promotion") enumerated below:

1) entirely consistent behavior with what the Debian Borg enclave advocates
2) epoch isn't forever: epoch becomes part of the comparison only when explicit and automatically is ignored when not present, either because versioning became "sane" after some hiccup, or because sloppy packaging/packagers has composted the original reason for an epoch.

OTOH, defaulting a missing epoch to 0 has the following advantages:

1) missing epoch is 0 is trivial to explain doing support
2) returning 0 instead of "not present" eliminates an error that application developers have forgotten to handle
3) the epoch comparison value returned is less contextually sensitive, all epoch values are WYSWYG

One can devise extreme/confusing counter example failure cases for either choices of a default value for a missing element rather easily.

(asides)
What really needs to happen going forward in RPM is to change epoch to a string from an integer so that the rpmvercmp() comparison is identical for each member of the {E,V,R} tuple and patterns might reasonably used for epoch as well. YMMV, everyone's does.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/450#issuecomment-400341017
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180626/5eff5cc4/attachment.html>