I have Portage 2.1.2.2. Example of the vercmp() issue: >>> import portage >>> portage.vercmp("1_alpha","1_alpha0") 0 >>> portage.vercmp("1_alpha","1_alpha0_p1") 0 >>> portage.vercmp("1_alpha0","1_alpha0_p1") -1 The first patch i will attach fixes just this logical flaw: when comparing _alpha and _alpha0, vercmp() should not stop but rather continue, to compare later suffixes (or -rX revisions). But imho, it's not enough: having "_suffix == _suffix0" is bad for the exact same reasons that 1.0 should not be equal to 1.0.0 (different versions should be sortable, etc.). Also, there is an implicit "_p0" when a suffix lacks, which implies "1.0 == 1.0_p == 1.0_p0" (bad too imho). The 2nd patch i will attach changes that, so that "1.0_alpha < 1.0_alpha0" and "1.0 < 1.0_p < 1.0_p0". It is the one i would recommend for inclusion, but if there are good reasons that i don't know to preserve the current behavior. Reproducible: Always
Created attachment 113571 [details, diff] portage_versions_fix1.patch
Created attachment 113572 [details, diff] portage_versions_fix2.patch
offhand, 1.0_alpha === 1.0_alpha0 *should* be the case. Before changing this, would suggest scanning the tree for fallout also; at least the _alpha < _alpha0 change you're pushing, against it since the '0' is implicit. If you're going to go that route, you'd have to also make it so that 6.0 < 6.0-r0 . Better to modify repoman to ensure the versions are unique imo. Aside from that, the alpha !< alpha0_p1 is obviously a screwup :)
(In reply to comment #3) > offhand, 1.0_alpha === 1.0_alpha0 *should* be the case. Well, maybe, but then i don't see how this is coherent with "1.0 != 1.0.0" and "1.0 != 1.00". > If you're going to go that route, you'd have to also make it so that 6.0 < > 6.0-r0 . Imho, the implicit -r0 is a different beast. Revisions are specific to the Portage tree, and are used with Portage semantics in mind, so they are much less an issue. Lack of -rX is well known as a shortcut for -r0, and it is even crystal clear in the API: >>> portage.pkgsplit("cat/pkg-1.0-r0") ['cat/pkg', '1.0', 'r0'] >>> portage.pkgsplit("cat/foo-1.0") ['cat/pkg', '1.0', 'r0'] At the contrary, the whole point of versions is to put an order between some strings which come directly from upstream¹. There is no point to use shortcuts here. Devs do write some "foo-1.0_alpha.ebuild" for "foo-1.0_alpha" releases, and some "foo-1.0_alpha0.ebuild" for "foo-1.0_alpha0" releases. Introducing some arbitrary equivalences between some of this strings only reduces your possibilities to stay close to upstream's numbering scheme. If an upstream releases first an 1.0_alpha and then an 1.0_alpha0², it's obvious it is meant to be two different versions. What should the Gentoo dev do then? A "foo-1.0_alpha_p1.ebuild"? Why? So, in short, i really don't see the point of having this implicit 0. ¹ Sure, not every upstream fantasy can be allowed, but still that's where it comes form (we could have used some simple integers starting at 0 or 1 if we didn't care about staying as close as possible to that). ² Well, the only case i have in mind was rather a _beta2 following the _beta... which makes me think that "_beta == _beta1" could be a more accurate guess of upstream's intent than "_beta == _beta0" :-) > Before changing this, would suggest scanning the tree That, i agree. Not clear to me yet how i could scan for that exactly, but if it happens that this "_alpha == _alpha0" is used in the tree, then it's probably not worth changing it. In this case, what would you think of patch #3? It doesn't changes the "_blah == _blah0" behavior, but still removes the implicit "_p0" (this one, i hope you agree it comes from nowhere but implementation, and that nothing sane may rely on it in the tree).
Created attachment 113593 [details, diff] portage_versions_fix3.patch
(In reply to comment #3) > Before changing this, would suggest scanning the tree for fallout So, i have qgreped the tree with '-[0-9]\+\(\.[0-9]\+\)*[a-z]\?_\(beta\|alpha\|pre\|rc\|p\)0\?\>', which gives few results. The most common patterns are ">=foo/bar-1.0_suffix" or "<foo/bar-1.0_suffix", which would be safe with this change. Filtering other random false-positives, i'm left with this three ones: dev-libs/pwlib/pwlib-1.8.4.ebuild:29: !>=media-libs/libdc1394-2.0.0_pre0 ) dev-libs/pwlib/pwlib-1.8.7.ebuild:28: !>=media-libs/libdc1394-2.0.0_pre0 )" x11-apps/ico/ico-1.0.1.ebuild:12: RDEPEND=">=x11-libs/libX11-0.99.1_pre0" According to the cvs' attic, there has never been any "media-libs/libdc1394-2.0.0_pre" or "x11-libs/libX11-0.99.1_pre" ebuild, so i think the "_suffix != _suffix0" change would be safe (eclasses are clean too).
_suffix == _suffix0 is good 1-r1 > 1_p0 (assumption of _p0 if not specified) is not. It's currently hurting ntp, which has versions: 4.2.4_p0 and 4.2.4-r1 where _p0 should be obviously newer.
*** Bug 177250 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > Created an attachment (id=113593) [edit] > portage_versions_fix3.patch Thanks, this is in svn r6484:6486.
This has been released in 2.1.2.7.
