Comment 20 for bug 633742

You can plug whatever versioning scheme you
wish, with whatever collate sequence you desire.

But the mixed mode comparison pathologies
need to be pinned down precisely in explicit
test cases before anything can be "supported".

Saying "Just like Debian!" isn't sufficient either,
even though the Debian comparison (or at least my
rewrite of dpkgcmp code, none has ever bothered
to confirm correctness) has been in RPM for years.

The hysterical issues in rpmvercmp are largely
    1) comparison between, say, digit <-> punctualtion is surprising
    the actual comparison is with "" (or missing or empty) and
    the (arbitrarily defined) comparison result isn't what people
    expect (which is ASCII or float based)

    2) digit padding means that 1.0000000002 > 1.1

    3) strcmp (as in glibc) means that case isn't distinguished.

    4) (mandriva and disttag related) many distros wish a "branding"
    identifier like
            foo-1.2-3mdv2011
    Sadly the distro "branding" bigots also wish the explicitly "branded"
    version to be "newer" than the unbranded version, which breaks
    the natural ASCII (or LC_COLLATE but lets ignore encoding issues) collation

   5) the '-' character is forbidden in version strings. and ':' is almost forbidden
   for similar reasons: rpm MUST be able to split "E:V-R" strings like
        Requires: foo = E:V-R
   into a tuple of {E,V-R} on known boundaries (both '-' and ':' are boundaries)

There's also the additional twist(s) of twiddle-in-epoch and twiddle-in-release
that twiddle-in-version will surely lead to RFE's for.

So tests cases to handle missed-class comparisons, and with missing values,
and '~' in other locations, possibly multiple, with regression tests are needed
to be acceptable for inclusion in RPM itself.

Again, all the RPM itself needs is a boolean return from an opaque comparison.
But "RPM sux! because it doesn't do what Debian does!" (and interoperability
in general) isn't enhanced by opaque pluggable comparisons.