EAPI names should be restricted just like category names etc. are. I propose [A-Za-z0-9+_-]* as the regular expression they must match. see http://bugs.gentoo.org/show_bug.cgi?id=217383#c5 Reproducible: Always
No. Doing so would be a veeeeeeery bad idea. Here's why. PMS currently specifies all legal values for EAPI. Those values are "0", "1" and "kdebuild-1". PMS also mandates that package managers do absolutely nothing other than string equality comparisons with EAPI values. Let's say we change this. Say we require EAPI to be \w+ or whatever. Then, package managers are expected to enforce this. Now, let's say a future EAPI introduces new syntax. EAPI="|| ( 3 4 )" or whatever -- the syntax isn't relevant so long as it isn't \w+. With the way things are currently, upon encountering EAPI="|| ( 3 4 )", a current package manager will realise that it the ID uses an unsupported EAPI, and will correctly treat the ID as masked by EAPI. With your proposed change, a current package manager will instead see an *invalid* EAPI, and reject the ID as being broken rather than unsupported. So the only thing that will change by introducing this is that future EAPIs will be arbitrarily restricted in what they can do -- the opposite effect of what you're trying to achieve.
(In reply to comment #1) > No. Doing so would be a veeeeeeery bad idea. Here's why. > > PMS currently specifies all legal values for EAPI. Those values are "0", "1" > and "kdebuild-1". PMS also mandates that package managers do absolutely nothing > other than string equality comparisons with EAPI values. This kills GLEP 55 in its current form for example (image a EAPI-name containing a slash). Most current package managers are heavily filesystem-based. Im not a friend of GLEP55 and this is just an example, but not specifying a restriction on the contents of EApi is just a disaster waiting to happen.
No, the concept of GLEP 55 can be extended arbitrarily no matter what. An EAPI containing / would just mean we'd need a different mapping for extensions. See the kdebuild stuff for example -- it uses .kdebuild-1, not .ebuild-kdebuild-1. But the issue here isn't really including / in EAPI. The issue is that imposing any restriction upon EAPI means we can't do anything different with EAPI in the future.
(In reply to comment #3) > The issue is that imposing > any restriction upon EAPI means we can't do anything different with EAPI in the > future. Since future EApis can redefine the whole interpretation and interaction with an ebuild thats agrument is pointless. EApi 2 can modify the complete interaction between ebuild and the package manager. It can introduce new variables to be set an in the ebuild and interpreted by the package manager. So, any reason left why eapi names shouldnt be specified in a sensible way?
No! No no no no no no no. You're completely missing the point. Future EAPIs can only change how EAPI is interpreted if current package managers impose no restrictions upon EAPI. Re-read comment#1 until you understand this.
(In reply to comment #5) > No! No no no no no no no. You're completely missing the point. Future EAPIs can > only change how EAPI is interpreted if current package managers impose no > restrictions upon EAPI. Re-read comment#1 until you understand this. Comment #1 is void of an valid argument. Introducing logic like the one mentioned in Comment #1 is _not_ needed in the EAPI variable. Since EAPI can redefine the interpretation of an ebuild any value in EAPI other than "", "0" or "1" can be used to trigger a completly new behavior. The stuff in comment #1 is possible by setting EAPI to "3" and ALL_SUPPORTED_EAPIS to "|| (3 4)". One of the flaws with the current use of EAPI is that it couples metadata extraction and ebuild syntax/grammar and expected package manager behaviour. The externally visible EAPI should only define the syntax for metadata extraction, not anything beyond it. Thats basic CS.
Now you're making even less sense. Please don't comment further until you understand why imposing syntax restrictions upon EAPI is directly at odds with the problem EAPI is trying to solve. PMS already defines exactly what all valid values of EAPI are, along with package manager behaviour when something else is encountered. Nothing more is necessary or desirable.
(In reply to comment #6) > One of the flaws with the current use of EAPI is that it couples metadata > extraction and ebuild syntax/grammar and expected package manager behaviour. > The externally visible EAPI should only define the syntax for metadata > extraction, not anything beyond it. Thats basic CS. Care to point out any piece of CS literature on the use and meaning of EAPI? Or perhaps course materials from a respected university? If it's so basic, there must be plenty for you to choose from, right?
So your point is: "We need to keep EAPI unspecified so we can do anything with it later. Like putting the ebuild in a uuencoded MS Word .doc file in EAPI prefixed by XXX in there (hey, its gotta be different from "", "0" and "1"). Of cause, everything we specified in pms does not apply to _that_ ebuild - actually its a whole new format. Not specifying EAPI is a loophole. Actually it renders the PMS useless. The whole point of a spec is to ensure invariants, so implementers can build upon that. Making a spec imprecise for fear of having to change or extend it is the worst fate of a spec. "Care to point out any piece of CS literature on the use and meaning of EAPI? Or perhaps course materials from a respected university? If it's so basic, there must be plenty for you to choose from, right?" - Read this: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html - Apply to the two concerns "metadata extraction" (pre-emerge) and "build/merge/other package manager behavior" (in and postmerge). Anyway, I give up here. I will not support the refinement of the pms here as it points out to be useless. Future concerns will go directly to the council when the pms is discussed there.
(In reply to comment #9) > So your point is: "We need to keep EAPI unspecified so we can do anything with > it later. Like putting the ebuild in a uuencoded MS Word .doc file in EAPI > prefixed by XXX in there (hey, its gotta be different from "", "0" and "1"). Of > cause, everything we specified in pms does not apply to _that_ ebuild - > actually its a whole new format. No no no no no. We need to avoid imposing restrictions that would prevent us from doing things like EAPI="|| ( 3 4 )" later on. Since we don't know what the exact syntax is going to be, that means we can't impose any real restriction at all. > Not specifying EAPI is a loophole. Actually it renders the PMS useless. The > whole point of a spec is to ensure invariants, so implementers can build upon > that. Making a spec imprecise for fear of having to change or extend it is the > worst fate of a spec. EAPI is specified, and is specified exactly as precisely as it needs to be. The invariant is that it is a string, and that the string is either equal to one of the defined values, in which case that EAPI is used, or not equal to one of the defined values, in which case the ebuild uses an unknown unsupported EAPI. > "Care to point out any piece of CS literature on the use and meaning of EAPI? > Or perhaps course materials from a respected university? If it's so basic, > there must be plenty for you to choose from, right?" > - Read this: > http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html > - Apply to the two concerns "metadata extraction" (pre-emerge) and > "build/merge/other package manager behavior" (in and postmerge). Uh... Nothing there to back up your point. EAPI as a concept is not restricted to metadata. > Anyway, I give up here. I will not support the refinement of the pms here as it > points out to be useless. Future concerns will go directly to the council when > the pms is discussed there. You've yet to come up with any kind of explanation of why it's ok to force us not to use something like EAPI="|| ( 3 4 )" at any point in the future. So answer that first -- why should we guarantee that in the future we will not use something like EAPI="|| ( 3 4 )"?
(In reply to comment #9) > Of cause, everything we specified in pms does not apply to _that_ ebuild - > actually its a whole new format. Please explain what the point of trying to place restrictions on future EAPIs is, when you've already admitted that future EAPIs are not bound by any restrictions placed by the current spec. > - Read this: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html > - Apply to the two concerns "metadata extraction" (pre-emerge) and "build/merge/other package manager behavior" (in and postmerge). I don't see any mention of EAPI on that page.
(In reply to comment #10) > You've yet to come up with any kind of explanation of why it's ok to force us > not to use something like EAPI="|| ( 3 4 )" at any point in the future. So > answer that first -- why should we guarantee that in the future we will not use > something like EAPI="|| ( 3 4 )"? If would have read my proposal in bug 217383 carefully, you will realize that if only want to restrict the EAPI name and I dont want to restrict the EAPI variable to [A-Za-z0-9+_-]*. However the _names_ of EAPI should be restricted to [A-Za-z0-9+_-]*. In the example of EAPI="|| ( 3 4 )" the names would be "3" and "4" but not "|| ( 3 4 )". Actually, an implementation that enables EAPI="|| ( 3 4 )" needs such a restriction on the names of EAPIs (the names of EAPIs here are "3" and "4") - the syntax fails for EAPIs names containing spaces for example. see http://bugs.gentoo.org/show_bug.cgi?id=217383#c4 where I describe exactly that scenario.
There's no point on a restriction on names either, since package managers can do absolutely nothing with that restriction.
(In reply to comment #13) > There's no point on a restriction on names either, since package managers can > do absolutely nothing with that restriction. Well, if you do not restrict names, any name can be use by anyone. There is no restriction on who can bring up an eapi (otherwise kdebuild-1 would not exist). If someone creates an EAPI named " " that does not contradict the pms. But you couldnt use the syntax proposed in comment 2. That would suck.
Sure, someone could create an EAPI named " ". And someone could create an EAPI named "monkey" where DEPEND is specified by a string of whitespace where spaces represent binary zero and tabs represent binary one, decoded into UTF-8. And if anyone did either of those, none of the package managers would implement the EAPI and the EAPI wouldn't get used anywhere that matters.
(In reply to comment #15) > Sure, someone could create an EAPI named " ". And someone could create an > EAPI named "monkey" where DEPEND is specified by a string of whitespace where > spaces represent binary zero and tabs represent binary one, decoded into UTF-8. > > And if anyone did either of those, none of the package managers would implement > the EAPI and the EAPI wouldn't get used anywhere that matters. Right now some EAPI creator might avoid spaces. Some other might use spaces, but avoid UTF-8. Another might avoid ":" but use UTF-8. And in the end you will find no sensible grammar will work with all of them. This is why the pms should restrict the names. Or at least contain a recommendation. Dont tell me, "not using space is common sense", common sense is different for different people. This is why specs exist, you know.... Also if there is a real need for names not matching [A-Za-z0-9+_-]* the spec can remove the restriction in an later version.
PMS restricts the names to "0", "1" or "kdebuild-1", and defines behaviour for when those restrictions are not met. That's all that's necessary. There's absolutely no point in using any further restrictions, since package managers can't enforce them without breaking future EAPIs.
This has been fixed long since (in 2012). (In reply to Björn Michaelsen from comment #0) > I propose [A-Za-z0-9+_-]* as the regular expression they must match. We've allowed the dot as well, i.e., the regexp is: [A-Za-z0-9+_.-]* https://projects.gentoo.org/pms/7/pms.html#x1-240003.1.8 https://projects.gentoo.org/pms/7/pms.html#x1-630007.3.1
