This ought to be assigned to pms-bugs@gentoo.org, I think. This is a bug in the specification "HEAD", under section 5.2.4. It states: "A variable name must start with one of a-zA-Z and may contain a-zA-Z0-9_-." The following conversation occurred in #gentoo-portage: 15:24 < ABCD> of course, the spec is wrong in allowing "-" in a variable name 15:25 < javaJake> ABCD: but it's in the spec 15:25 < ABCD> javaJake: but the spec is wrong :) Thus, this report. ;)
And why is a dash not allowed? Could you give me a pointer?
Because bash itself doesn't allow dash characters in variable names, and make.defaults is essentially a big bash script.
It's not a bash script.
(In reply to comment #3) > It's not a bash script. But it's profile-like and you could source it from a shell. So IMHO it would be wise to restrict the allowed characters to the ones that POSIX allows <http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_230>: "a word consisting solely of underscores, digits, and alphabetics from the portable character set. The first character of a name is not a digit." (In reply to comment #0) > [...] may contain a-zA-Z0-9_-." The full stop should also be disallowed, by the way.
POSIX there is much more restrictive than Unix. It's perfectly legal to have an environment variable with a hyphen or a dot in the name. Is there any reason to believe that we won't, for example, introduce ABI values that have a hyphen in them in the future? I ask because if the rules change, Paludis will enforce it and Portage likely won't, which in turn means as soon as people start relying upon something that PMS declares illegal, there will be the usual cries about PMS being a Paludis conspiracy and how PMS should be fixed...
(In reply to comment #5) > POSIX there is much more restrictive than Unix. It's perfectly legal to have > an environment variable with a hyphen or a dot in the name. Every character except = and NUL is legal in environment variables I think. But valid identifiers in bash may not contain any hyphens. And PMS itself states that make.defaults uses "a small subset of bash syntax", so currently it's self-contradictory. > Is there any reason to believe that we won't, for example, introduce ABI > values that have a hyphen in them in the future? This doesn't sound very useful to me, especially if the price to pay is the loss of shell compatibility.
Actually, dots are a better example... PYTHON_ABI=2.5, and then PYTHON_ABI_2.5_BLAH=something comes to mind. *shrug* I'm not opposed to changing it, but if we do, it's probably wise to make sure Portage enforces it.
(In reply to comment #7) > Actually, dots are a better example... PYTHON_ABI=2.5, and then > PYTHON_ABI_2.5_BLAH=something comes to mind. Hm, but the _source_ of profiles.tex shows that the dot is already disallowed: # A variable name must start with one of \t{a-zA-Z} and may contain # \t{a-zA-Z0-9\_-}. The full stop denotes end of sentence here. ;-) But it is very misleading, maybe the sentence should be rearranged to have at least one word after the charset. > *shrug* I'm not opposed to changing it, but if we do, it's probably wise to > make sure Portage enforces it. Portage silently ignores variables with a dash in their name, and neither exports them to the ebuild environment nor saves them in the VDB. I think that's good enough.
(In reply to comment #8) > The full stop denotes end of sentence here. ;-) But it is very misleading, > maybe the sentence should be rearranged to have at least one word after the > charset. Yeah, I generally try to do that, but don't always remember. Perhaps someone could make a patch for all of the existing cases of that... > Portage silently ignores variables with a dash in their name, and neither > exports them to the ebuild environment nor saves them in the VDB. I think > that's good enough. Alright. Although I'd still prefer it if this could get updated to warning noisily. Silently skipping things scares me.
Created attachment 202348 [details, diff] Quick fix for the ambiguous wording (In reply to comment #9) > (In reply to comment #8) > > The full stop denotes end of sentence here. ;-) But it is very misleading, > > maybe the sentence should be rearranged to have at least one word after the > > charset. > > Yeah, I generally try to do that, but don't always remember. Perhaps someone > could make a patch for all of the existing cases of that... The attached one fixes the wording, but still includes the dash in the last. Do we want to remove it? > > Portage silently ignores variables with a dash in their name, and neither > > exports them to the ebuild environment nor saves them in the VDB. I think > > that's good enough. > > Alright. Although I'd still prefer it if this could get updated to warning > noisily. Silently skipping things scares me. I told Zac via IM, he wants to fix that.
(In reply to comment #10) > The attached one fixes the wording, but still includes the dash in the last. > Do we want to remove it? I would say yes. No one is opposed, and by removing the dash the PMS is more consistent and things work (like a bash script) the way people expect them to. (The only argument against this change was "It's not a bash script." but the response "PMS itself states that make.defaults uses 'a small subset of bash syntax" and "valid identifiers in bash may not contain any hyphens" showed how it is really a very simple bash script.)
(In reply to comment #10) > I told Zac via IM, he wants to fix that. Fixed: http://sources.gentoo.org/viewcvs.py/portage?rev=14167&view=rev
(In reply to comment #10) > The attached one fixes the wording, but still includes the dash in the last. > Do we want to remove it? Yes, definitely.
Created attachment 202800 [details, diff] Updated patch without dash in character list
So no objections if I commit above change?
wfm
Committed.
