Eapi names should be restricted just like package names etc. are. I propose [A-Za-z0-9+_-]* as the regular expression they must match. The EApi variable set in ebuilds should however only be resticted to this for further EApis. The way information gets submitted to the package manager in the EApi variable can be different in further EApis. RATIONALE 1) Example: package managers only supporting a subset of an official EApi In addition to completing the spec this enables later EApis to allow define an interface-like interaction between Ebuild and package manager. Example: An package manager supports the EApis 0,1,2 and kdelibs-1, but not EApi 3.(*) The Ebuild sets EAPI="3 kdelibs-1 pkgcore-3 paludis-2" and thus does guarantee to work with EApi3 or with kdelibs-1, pkgcore-3 or paludis-2, but not with other EApis. This enables a package manager, which only supports a subset of the official EApi3 to use the ebuild anyway. This is desireable and allows a more gradual development of EApis. 2) Example: Merge-only package managers This enables the creation of an very lightweight package merger that doesnt build, or depresolve, but is only able to merge binpkgs (having a very limited Eapi). This possibility shouldnt be needlessly ruled out by restrictions in the PMS. CONCLUSION I think this solution is defining current expected package manager very well, without restricting further EApis too badly. The multi-EApi stuff in the rationale should not be part of the EApi, of cause. Thats stuff for an GLEP. Opinions? Restrictions which EApis are allowed in the portage tree are independent of this, of cause. (*) Multi-EApi support is defined in EApi 2 in this example. Reproducible: Always Steps to Reproduce:
Arrgh, "The EApi variable set in ebuilds should however only be restricted to this for further EApis." should say "The EApi variable set in ebuilds should however _not_ be restricted to this for further EApis." Doh!
"The multi-EApi stuff in the rationale should not be part of the EApi, of cause. Thats stuff for an GLEP." should say "The multi-EApi stuff in the rationale should not be part of the PMS, of cause. Thats stuff for an GLEP." I need to adjust my caffeine dosage.
No. Ebuilds can't have multiple EAPIs.
How about reading the bug actually? That would kinda help. The spec is missing a restriction on EApi names. Thats bad and needs to be fixed. The stuff in "rationale" only describes why such a limitation, _when_ added to the pms should not extend to further EApis for the EApi variable set in ebuilds. The pms needs to be modified as follows: 1) "EApi names should match the following regular expression: [A-Za-z0-9+_-]*." This is to prevent ugly stuff like UTF-8 or binary eapi names. 2) ("The EApi variable in Ebuilds in further EApis is not limited by this restriction." This is optional, but a good idea for not making later extensions impossible. Currently EApi names are not limited in any way. The could even contain newlines, spaces, UTF-8 and binary data. Is it really hard to understand that thats a bad idea? "No. Ebuilds can't have multiple EAPIs." Actually with the current pms, later EApis could allow that just like described above - nothing in the pms prevents this. So you completely missed the point. If you add only point 1) then the pms would enforce such restrictions. However adding 2) also is a good idea, because it prevents the limitation to restrict the options for further Eapis. And please, try to read and understand the text actually before marking it invalid again this time. And consider points 1) and 2) separately.
"EAPI names should be restricted just like package names etc. are. I propose [A-Za-z0-9+_-]* as the regular expression they must match." Björn, I agree with you that the legal chars for EAPI names should be defined. And that's all you should have stated because multiple EAPI support in ebuilds (which is not legal) is a complete different issue.
Hmmm, you can leave out point 2 because an upcoming EApi might solve this with a prefix and a separator. E.g. EAPI="4:paludis-2:pkgcore-4" not exactly beautiful (esp. if you need to escape ':'), but it would work ... Still: fix point one, please. @philantrop: Yes, my fault.
Please create a new bug without all the nonsense in it if you think you have something to say. As it stands, there's so much noise here that if you have any valid points they're completely lost.
(In reply to comment #7) > Please create a new bug Done. see http://bugs.gentoo.org/show_bug.cgi?id=217420
