On Thu, 2007-12-20 at 14:08 +0100, Thomas de Grenier de Latour wrote: <snip>
Seems that there is a chain of different metadata levels: 1) The parser/interpreter/compiler/whatever to grok the ebuild. 2) *How* to extract the EAPI value from the ebuild(-filename), using 1) 3) The *value* of EAPI for that ebuild, using 2) 4) The contents of the ebuild, based on 3) To 1: for me it's absolutely acceptable to have it encoded in the filename (or extension). Fex we want to switch from bash to xml (for whatever reason), we could rename from *.ebuild to *.xbuild. > But yeah, to be honest, you're right that my original "as long as > ebuilds stay bash" was a bit optimistic: it was assuming there would > be no decision of changing that rule as long as there would be no good > reason for it (like a switch to xml or whatever other not-bash > format). To 2: it might be acceptable to have it encoded into the filename. To 3 (and 2): Thomas++ > I still think that changing file names when absolutly required > (switching from "EAPI=foo" to "eapi foo", or moving it elsewhere, or > switching to xml, etc.) is less disturbing than changing it for every > single new EAPI. It's not because one new extension may not be > eternally enough that we should introduce an infinity right now. To 4: we agree that this never will be encoded in the filename ;) Just another bit of brainstorm (forget it if too broken): What if we do not start with "EAPI=1" variable, but "eapi 1" function immediately ? I could think of several implementations to let PM detect EAPI: *) Given it is the first bash-command in the ebuild: Just 'echo' the required EAPI and exit while PM is in "look-for-eapi" mode (remember 'eapi' function is part of PM, or profile.bashrc as fallback for ancient PM). *) As 'eapi' being a bash function, it could *migrate* the bash-environment from the PM's default EAPI to the given one - or just spit "cannot migrate EAPI from A to B"... *) Or just spit a message "update your PM" (from profile.bashrc) ... Just want to show that using 'eapi-function' should be more flexible than 'EAPI-variable', and thus will not be subject to change too often and require 2) (see above). /haubi/ -- Michael Haubenwallner Gentoo on a different level -- [EMAIL PROTECTED] mailing list
