Bug 51135

Summary:	Version comparison of 3.0, 3.0.0, 3.0.0.0 odd
Product:	Portage Development	Reporter:	Dan Armak (RETIRED) <danarmak>
Component:	Core - Ebuild Support	Assignee:	Portage team <dev-portage>
Status:	RESOLVED DUPLICATE
Severity:	normal
Priority:	High
Version:	unspecified
Hardware:	All
OS:	All
Whiteboard:
Package list:		Runtime testing required:	---

Description Dan Armak (RETIRED) gentoo-dev

2004-05-15 08:04:36 UTC

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.

Comment 1 Nicholas Jones (RETIRED) gentoo-dev

2004-05-19 15:54:01 UTC

*** This bug has been marked as a duplicate of 37406 ***

*** This bug has been marked as a duplicate of 37406 ***