currently portage has the behavior that numbers that start with 0 are compared as floats rather than integers ... the comparison does cause a few discrepancies (probably less than 10 in the current tree) comparing by float, portage says: dev-perl/WWW-Mechanize-1.0301 is older than dev-perl/WWW-Mechanize-1.16 comparing by int, the pms says the opposite
Is this behaviour really desirable? As far as I can recall, last time I checked the only ebuilds using this behaviour were some now removed perl modules. That may of course have changed, or I may just be wrong. Personally, I view the float comparison as a nasty hack to be dumped at a reasonable opportunity.
It's also inconsistent for Perl things as soon as the leading zero becomes a one... The whole leading-zero comparison is inconsistent, ill-defined and illogical.
i'd agree it can be illogical, but this difference needs to be at least noted in the spec i think plus we need to fix portage
Im seeing the error in the following ebuilds dev-perl/MailTools-1.67 dev-perl/MailTools-1.74 which both DEPEND=">=virtual/perl-libnet-1.0703 of course virtual/perl-libnet exsists only as version 1.19 & 1.20 in the tree. Apparently fixing the depend line in the ebuild manually also ends in tears http://bugs.gentoo.org/show_bug.cgi?id=165971 In short, its apparently a problem right now.
Ok. Someone please come up with an algorithm that can explain the following ordering: 0_pre 00 0 1_alpha_alpha 1_alpha 1_alpha1_alpha 1_alpha1_beta_pre 1_alpha1_beta 1_alpha1 1_alpha1-r1 1_alpha10 1_alpha10-r1 1_alpha10-r2 1_alpha10_p1 1_alpha10_p1-r1 1_alpha11 1_beta 1_beta10 1_beta10-r1 1_beta10_p1 1_beta10_p1-r1 1_beta11 1_pre 1_pre10 1_pre10-r1 1_pre10_p1 1_pre10_p1-r1 1_pre11 1_rc 1_rc10 1_rc10-r1 1_rc10_p1 1_rc10_p1-r1 1_rc11 0001 01 1 001 1-r1 1_p1 1p 1.0 1.00 1.0a 1.0.0 1.001 1.010 1.01 1.02 1.020 1.021 1.1_alpha3 1.1 1.1-r1 1.1.1 1.1.2 1.2_alpha 1.2_beta 1.2_beta10 1.2_beta10_p1 1.2_beta11 1.2 1.2-r1 1.10 1.11 1.100 1.101 1.201 2_alpha 10 100 Note in particular this part: 0001 01 1 001 To obtain that list, I created ebuilds for a dummy package with all of those version numbers and then ran equery list, which is supposed to stick them out in order. Cc:ing the Portage people in the hopes that they can explain just what the heck is going on...
(In reply to comment #5) > Note in particular this part: > > 0001 > 01 > 1 > 001 The version comparison code does not distinguish between any of those. It simply strips all of the leading zeros in that case. Proof: #!/usr/bin/env python test_versions = ["0001", "01", "1", "001"] from portage_versions import vercmp for x in test_versions: for y in test_versions: if x == y: continue print "%s = vercmp('%s', '%s')" % (vercmp(x, y), x, y)
Alright, so what's the algorithm? It's not float-like, since 1.1 != 1.10, and it's not integer, since 1.01 != 1.1, and it's not string, since 1.010 < 1.01.
It's an integer comparison, with the leading zeros ignored. The float-like behavior is only triggered when the zeros come after a period.
(In reply to comment #8) > It's an integer comparison, with the leading zeros ignored. The float-like > behavior is only triggered when the zeros come after a period. So what's the behaviour then? It's not float-like because 1.10 != 1.1.
Float comparison is only triggered when both components being compared come after a period and both begin with zero.
(In reply to comment #10) > Float comparison is only triggered when both components being compared come > after a period and both begin with zero. So going back to comment #0, why is 1.0301 < 1.16? That's not both beginning with a zero.
(In reply to comment #10) > Float comparison is only triggered when both components being compared come > after a period and both begin with zero. I said that wrong. I should have said "Float comparison is only triggered when both components being compared come after a period and either component begins with a zero".
Hrm. Are these two equal too then? 1.010 1.01
Yes, 1.010 and 1.01 trigger the float comparison code which considers them equal.
Alright, please look at r163. I thiiiink that matches up with the mess that Portage uses...
Fixed in SVN as of r163.
*** Bug 207515 has been marked as a duplicate of this bug. ***
The current description makes: 1.22<1.050 1.6<1.22 1.050<1.6 Ebuilds version comparisons are not transitive, making it impossible to find a best match in this case (those versions cant be ordered). This is not only strange, it leads to undefined behavior. For example a package manager might always "update" between the versions above, as each is of the versions is higher than one other. Thats clearly broken. Proposal: - A missing version component is always less than any given version component. - Version components with a leading zero are always less than version components starting with [1-9]. - Two Version components with leading zeros are always stripped from leading zeros and are then string compared. - Version components with no leading zero are compared as integers. The last sentence is the only difference to the behavior in r174 of PMS. However the current description for that case leads to undefined behavior anyway. That comparison is transitive and as close to the original behavior as possible: - It only makes 1.01 < 1.1 - It keeps 1.01 == 1.001 and 1.0100 < 1.000050 - It keeps 1.23 > 1.9 Please reopen this bug. The current state (r174) is no solution. Thanks.
(In reply to comment #18) > The current description makes: > 1.22<1.050 I don't see how you get that from the text... certainly none of the implementations do it: [dleverton@shiny-one ~] $ python Python 2.4.4 (#1, Oct 27 2007, 11:37:00) [GCC 4.1.2 (Gentoo 4.1.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import portage_versions >>> portage_versions.vercmp("1.22", "1.050") 170 >>> import paludis >>> paludis.VersionSpec("1.22") > paludis.VersionSpec("1.050") True >>> import pkgcore.ebuild.cpv as cpv >>> cpv.native_CPV("foo", "bar", "1.22") > cpv.native_CPV("foo", "bar", "1.050") True >>> cpv.cpy_CPV("foo", "bar", "1.22") > cpv.cpy_CPV("foo", "bar", "1.050") True
@David: Yes, sorry. I misunderstood the text. (I read "strip leading zeroes" instead of "strip tailing zeroes".) I will ponder a bit about this, before raising my voice again.
