Specifically, this affects esdl-1.0.1 dependency checks. It requires >12.2b, only stable version for x86 is 12.2.5-r1 Quoting (and skipping irrevalent parts): Version specifications are compared component by component, moving from left to right. ... Note in particular that \t{1.0} is less than \t{1.0.0}. ... Letter suffixes are compared alphabetically, with any letter being newer than no letter. The wording could use work anyways to be clearer, but the history of the parser here has always been delimited by '.', and comparing chunks- 2b > 2 makes sense in that regard. Either way, if .2b is to be less then .2.5, then the wording needs to be clearer. If I'm interpretting it correctly, then paludis/portage need to be fixed (or PMS changed).
"If one number part is a prefix of the other, then the version with the longer number part is greater." Isn't it already covered by that, and doesn't that match what Portage and Paludis do?
So far as I can see, Portage, Paludis and PMS all agree on this.
Revision 2309 of portage (11/13/05) is where this changed from 12.2b > 12.2.5 to 12.2b < 12.2.5. The commit msg is a bit telling- "Backport of version code rewrite (bug 37406), should be completely backwards compatible (and the algorithm has been tested on the whole tree multiple times already)." Further, the bug in question actually directly counters this change- comment #12 and comment #13 (in particular 13)- "As I said in comment #1 the new behavior seems to have more support by devs (IIRC the people who answered were vapier, weeve, ciaranm and bazik). The ebuild docs don't cover this case, so nobody should rely on the current behavior. The logic behind this is that 2b should be the same as 2b.0.0 which would be newer than 2.1.0 (as 2b > 2)." Same goes for comment #16. Basically... this wasn't intended (and was objected to when the patch was posted w/ folk, including via hearsay, you ciaran) w/ the stating 2b.0.0 > 2.1.0 being how it should behave. So... the current behaviour *was* a bug, and a reversion of the preexisting long term behavior. Only reason it slid by is a year plus went by since the patch was posted, and it got pulled in blindly (basically). Essentially, at the time the patch was posted quite a few folk weighed in against it as being the wrong behaviour- it still is the wrong behaviour. It's existance in pms doesn't mean we should leave it broke however.
The changed behaviour has been changed for so long that it's standard now. We shouldn't be going back to a really old behaviour even if it was originally a screw-up. The way PMS has it and Portage had it until a few minutes ago is the accepted standard. Reassigning to dev-portage so they can revert recent commits on this.
"Version specifications are compared component by component, moving from left to right." PMS doesn't define what a "component" is, so you can interpret it in either way. If "2b" is a component then 12.2b > 12.2.5 because 2b > 2.
It does say "letter components" in several places, though, which makes it pretty clear that a letter is a component of its own.
(In reply to comment #5) > "Version specifications are compared component by component, moving from left > to right." > > PMS doesn't define what a "component" is, so you can interpret it in either > way. Ever since that sentence has been in there (in both the English and pseudocode descriptions), it's been an initial summary of the rules, followed by a detailed description.
(In reply to comment #6) > It does say "letter components" in several places, though, which makes it > pretty clear that a letter is a component of its own. I fear we have to use the last council-approved version here, which doesn't mention "letter components". It however says "components of the number part" so it seems clear that the intention was first to compare 12.2 with 12.2.5 before considering the suffix letter. (But still, the wording could be clearer: it should say how components are separated.) BTW, there's only one package in the portage tree where this would affect internal ordering of versions: net-im/pyicq-t. I haven't checked dependencies though.
(In reply to comment #4) > Reassigning to dev-portage so they can revert recent commits on this. It's reverted in r15166. I think most people would agree that 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.
I don't think we can really assume either as being clearly what upstream wants... Various upstreams use the letter part for things like betas, which just adds to the confusion. Unfortunately, we're pretty much stuck having to provide a global total order, so we have to make some arbitrary decision and stick with it, and the one we've been using for the past few years is as good as any other.
Two out of the 3 manager folk are for current behaviour, thus closing the bug- portage behaviour was reverted to the existing behaviour, pkgcore 0.5.9 was released matching 12.2.5 > 12.2b. Wording still sucks imo, but I doubt that's going to be changed...
