While packages shouldn't contain more than one of the above versions, the result of comparing such versions is to me very unintuitive. If it's not to be changed, I'd like an exact definition of its behaviour. Also, is it a part of the standard and can be relied on in future versions, or an undefined case? What I see is this: 3 > 3.<any amount of zeros> 3.0.0 > 3.0 3.0.0.0 < 3.0.0 3.0.0.0.0 > 3.0.0.0 (continues in cycles of 3 or 4, AFAICS) This is using portage 2.0.50-r6. jstubbs on irc says he can't reproduce it by accessing portage.vercmp() directly, and I don't know how to do it, but it does happen if I create ebuilds with those versions and test with emerge -p. This behaviour completely broke the principle of least surprise for me. I'd have expected either of: - The fewer zeroes, the greater the version - The more zeroes, the greater the version The second of these seems the better choice, because in my experience when the versioning scheme of an ebuild needs changing (e.g. due to upstream change), the change adds a zero rather than removing one. But I say this based on only a couple of cases.
*** This bug has been marked as a duplicate of 37406 *** *** This bug has been marked as a duplicate of 37406 ***
