RPM version comparison oddity with release field

[wagoodman]

When taking a look at another RPM version-related investigation @luhring noticed the following oddity:

# this resolves to true
8.3.1-5.el8 < 0:8.3.1-5.el8.0.0

# this resolves to true
8.3.1-5.el8.0.0 > 0:8.3.1-5.el8

It appears that this could be falling back to string length (i.e. if the string is a subset of the other, then the longest string is "greater" than the other) --but I haven't verified this.

Both of these statements (I think) should resolve as "false". I've added these failing tests here: 138b1a2

This issue should:

1. at least determine if this behavior is unexpected or not
2. if there is a problem, fix it
3. identify other cases that may exhibit similar behavior (and add them as tests)

[dakaneye]

@wagoodman based on my analysis of how the RPM comparison code was written, I think the behavior is not unexpected, and is caused by what you said (the length of the string, more or less).

My analysis:

Example: 8.3.1-5.el8 < 0:8.3.1-5.el8.0.0

Left: 
Epoch: nil
Version: 8.3.1
Release: 5.el8

Right:
Epoch: 0
Version: 8.3.1
Release: 5.el8.0.0

The RPM version comparison appears to be doing the following:
    1. deep equal on the two version structs
    2. if an epoch is present on BOTH version structs, it compares the epochs and sorts them based on that
    3. compare the actual RPM versions, starting with the version then heading to release
        a. if the strings are equal, return 0
        b. parse as alphanumeric segments, iterate through them based on whichever segment is smallest
        c. compare the runes, giving precedence to numbers
        d. comparison favors the longer string
        
Based on my above analysis of the code flow, I think where we're getting hung up is on the Release comparison:
    - the left version doesn't have an epoch so we skip that part
    - the two structs aren't deeply equal
    - the versions are the same
    - the right version is alphanumerically longer so it takes precedence

This case is however isolated to RPM version comparisons only, so it shouldn't affect other types of package version comparisons.

We can certainly change the behavior, but it does appear to work as originally intended. I'll defer to you on a recommendation here.