summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorZac Medico <zmedico@gentoo.org>2010-01-04 21:30:22 +0000
committerZac Medico <zmedico@gentoo.org>2010-01-04 21:30:22 +0000
commit157e2065c3327e5cab22af9c74e9a46b47d18f29 (patch)
treef6cd4da2e6d87154c77ce58247950da48fd69969
parent9f39407d845820b8e864e1a0d03b8102936f5aa0 (diff)
downloadportage-157e2065c3327e5cab22af9c74e9a46b47d18f29.tar.gz
portage-157e2065c3327e5cab22af9c74e9a46b47d18f29.tar.bz2
portage-157e2065c3327e5cab22af9c74e9a46b47d18f29.zip
Revert r15161 so 12.2.5 is greater than 12.2b once again. Depending on how you
look at, it may seem counter-intuitive. However, if you really think about it, it seems like it's probably safe to assume that 12.2.5 > 12.2b is the behavior that is intended by anyone who would use versions such as these. svn path=/main/trunk/; revision=15166
-rw-r--r--pym/portage/tests/versions/test_vercmp.py8
-rw-r--r--pym/portage/versions.py27
2 files changed, 15 insertions, 20 deletions
diff --git a/pym/portage/tests/versions/test_vercmp.py b/pym/portage/tests/versions/test_vercmp.py
index 9de3344ce..eb2ba3eb0 100644
--- a/pym/portage/tests/versions/test_vercmp.py
+++ b/pym/portage/tests/versions/test_vercmp.py
@@ -18,11 +18,11 @@ class VerCmpTestCase(TestCase):
("cvs.9999", "9999"),
("999999999999999999999999999999", "999999999999999999999999999998"),
("1.0.0", "1.0"),
- ("1.0b", "1.0.0"),
+ ("1.0.0", "1.0b"),
("1b", "1"),
("1b_p1", "1_p1"),
("1.1b", "1.1"),
- ("12.2b", "12.2.5"),
+ ("12.2.5", "12.2b"),
]
for test in tests:
self.failIf( vercmp( test[0], test[1] ) <= 0, msg="%s < %s? Wrong!" % (test[0],test[1]) )
@@ -41,11 +41,11 @@ class VerCmpTestCase(TestCase):
("1.0-r0", "1.0-r1"),
("1.0", "1.0-r1"),
("1.0", "1.0.0"),
- ("1.0.0", "1.0b"),
+ ("1.0b", "1.0.0"),
("1_p1", "1b_p1"),
("1", "1b"),
("1.1", "1.1b"),
- ("12.2.5", "12.2b"),
+ ("12.2b", "12.2.5"),
]
for test in tests:
self.failIf( vercmp( test[0], test[1]) >= 0, msg="%s > %s? Wrong!" % (test[0],test[1]))
diff --git a/pym/portage/versions.py b/pym/portage/versions.py
index 208378172..5ab3aaeb5 100644
--- a/pym/portage/versions.py
+++ b/pym/portage/versions.py
@@ -103,22 +103,6 @@ def vercmp(ver1, ver2, silent=1):
if match1.group(3) or match2.group(3):
vlist1 = match1.group(3)[1:].split(".")
vlist2 = match2.group(3)[1:].split(".")
- else:
- vlist1 = []
- vlist2 = []
-
- if match1.group(5) or match2.group(5):
- # and now the final letter
- if match1.group(5):
- vlist1.append(str(ord(match1.group(5))))
- else:
- vlist1.append('0')
- if match2.group(5):
- vlist2.append(str(ord(match2.group(5))))
- else:
- vlist2.append('0')
-
- if vlist1 or vlist2:
for i in range(0, max(len(vlist1), len(vlist2))):
# Implcit .0 is given a value of -1, so that 1.0.0 > 1.0, since it
@@ -148,6 +132,17 @@ def vercmp(ver1, ver2, silent=1):
list1.append(int(vlist1[i].ljust(max_len, "0")))
list2.append(int(vlist2[i].ljust(max_len, "0")))
+ # and now the final letter
+ # NOTE: Behavior changed in r2309 (between portage-2.0.x and portage-2.1).
+ # The new behavior is 12.2.5 > 12.2b which, depending on how you look at,
+ # may seem counter-intuitive. However, if you really think about it, it
+ # seems like it's probably safe to assume that this is the behavior that
+ # is intended by anyone who would use versions such as these.
+ if len(match1.group(5)):
+ list1.append(ord(match1.group(5)))
+ if len(match2.group(5)):
+ list2.append(ord(match2.group(5)))
+
for i in range(0, max(len(list1), len(list2))):
if len(list1) <= i:
vercmp_cache[mykey] = -1