Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 618558

Summary: sys-apps/portage (and tools) should accept atoms with a version but without an equal/greater than/littler than sign preceding it
Product: Portage Development Reporter: Jeroen Roovers (RETIRED) <jer>
Component: CoreAssignee: Portage team <dev-portage>
Status: CONFIRMED ---    
Severity: normal CC: kripton, pms
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
See Also: https://bugs.gentoo.org/show_bug.cgi?id=503204
https://bugs.gentoo.org/show_bug.cgi?id=618560
https://bugs.gentoo.org/show_bug.cgi?id=618562
Whiteboard:
Package list:
Runtime testing required: ---

Description Jeroen Roovers (RETIRED) gentoo-dev 2017-05-15 19:05:17 UTC
package.provided accepts only atoms that are not preceded by an equal sign, so that should equally apply to all its other inputs, whether command line, configuration files or ebuilds.

Currently, passing an atom with a version but without [<>=] returns an error.
Comment 1 Zac Medico gentoo-dev 2017-05-15 19:29:47 UTC
This is doable, since there is no ambiguity. PMS guarantees that there is no ambiguity because it forbids package names that have a version-like suffix (this part of the spec was tightened for bug 174536).
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-05-15 19:37:49 UTC
I do not think it reasonable to relax Portage behavior here. The long-term mixing of different syntaxes has already resulted in absurd requirements in the PMS. We oughtn't use those requirements as an excuse to make things worse again. Especially that providing a valid input is not an issue.

If at all, we should strive to finally get rid of those requirements and be able to follow upstream naming independently of whether the author did consider that his name may accidentally match one of the very complex Gentoo version naming rules.
Comment 3 Ulrich Müller gentoo-dev 2017-05-15 20:43:19 UTC
(In reply to Michał Górny from comment #2)
> I do not think it reasonable to relax Portage behavior here. The long-term
> mixing of different syntaxes has already resulted in absurd requirements in
> the PMS. We oughtn't use those requirements as an excuse to make things
> worse again. Especially that providing a valid input is not an issue.

Removing the ambiguity was precisely the argument that was used in bug 174536 for tightening the requirements on package names (while I was much in favour of loosening them, see attachment 300745 [details, diff]). So it is only logical that Portage should follow up to this now.

If that is not going to happen, then there is no reason for the current PMS wording that package names "must not end in a hyphen followed by anything matching the version syntax".