Bug 178798 - rpm's version comparison is not antisymmetric
Summary: rpm's version comparison is not antisymmetric
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
(Show other bugs)
Version: 4
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Mike McLean
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-01-24 14:28 UTC by Roozbeh Pournader
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-13 18:22:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test C code that shows the problem (315 bytes, text/plain)
2006-01-24 14:28 UTC, Roozbeh Pournader
no flags Details
Fix to handle trailing null segments (1.06 KB, patch)
2006-02-07 07:57 UTC, Peter Bowen
no flags Details | Diff

Description Roozbeh Pournader 2006-01-24 14:28:08 UTC
Description of problem:
RPM's version comparison is not symmetric, that is rpmvercmp(a,b) is not always
equal to -rpmvercmp(b,a).

Version-Release number of selected component (if applicable):
rpm-4.4.1-22

How reproducible:
Always

Steps to Reproduce:
Compile and run the attached sample:
1. gcc -lrpm -o rpmcomp rpmcomp.c
2. ./rpmcomp
  
Actual results:
rpmvercmp ("+", "_") == -1
rpmvercmp ("_", "+") == -1

Expected results:
One of the results should be 1 and the other -1.

Additional info:
Please note that both "+" and "_" are valid RPM versions, as rpmbuild accepts
them both as the "Version:" field.

Comment 1 Roozbeh Pournader 2006-01-24 14:28:08 UTC
Created attachment 123615 [details]
Test C code that shows the problem

Comment 2 Jeff Johnson 2006-01-24 16:22:41 UTC
Yep. There are many problems with rpmvercmp, all known.

WONTFIX in the sense that the fix is worse than living with existing.

Comment 3 Peter Bowen 2006-02-06 16:33:19 UTC
Wow!  Never hit that corner case.  I don't have the code handy, but I'm pretty
sure that the concept of strings that only have segment delimiters isn't
handled.  To verify, please try to following tests:

rpmvercmp ("a", "a")
rpmvercmp ("a+", "a_")
rpmvercmp ("+a", "_a")
rpmvercmp ("+_", "+_")

I will try to look at the code today; I'm on a plane overnight, so I should have
some hacking time.

Comment 4 Peter Bowen 2006-02-07 07:54:51 UTC
After a little testing, the issue shows up for cases other than strings
containing only non-alnum chars.  It actually impacts string where the final
segment is null.  This means that comparing "4.1__" and "4.1+" is currently buggy.

It is a one line fix to resolve this issue.  We really should put some bounds on
acceptable values for version and release, but that is an issue for a different bug.

Comment 5 Peter Bowen 2006-02-07 07:57:01 UTC
Created attachment 124302 [details]
Fix to handle trailing null segments

This patch resolves the issue, and changes comments a little later in the
function to make the workings of rpmvercmp clearer.

Comment 6 Roozbeh Pournader 2006-02-07 12:17:10 UTC
Confirming that the patch fixes the problem, and also the extended problem of
when the string string ends in non-alphanumeric chars.

I guess I have also proved that this patch makes rpmvercmp antisymmetric, that
is rpmvercmp(x,y)==-rpmvercmp(y,x), the way it's supposed to be.


Comment 7 Jeff Johnson 2006-02-13 18:22:20 UTC
Added to rpm CVS, should be in rpm-4.4.5-0.11 when built.


Note You need to log in before you can comment on or make changes to this bug.