| 1 |
On Thu, 2007-12-20 at 14:08 +0100, Thomas de Grenier de Latour wrote: |
| 2 |
<snip> |
| 3 |
|
| 4 |
Seems that there is a chain of different metadata levels: |
| 5 |
|
| 6 |
1) The parser/interpreter/compiler/whatever to grok the ebuild. |
| 7 |
2) *How* to extract the EAPI value from the ebuild(-filename), using 1) |
| 8 |
3) The *value* of EAPI for that ebuild, using 2) |
| 9 |
4) The contents of the ebuild, based on 3) |
| 10 |
|
| 11 |
To 1: for me it's absolutely acceptable to have it encoded in the |
| 12 |
filename (or extension). Fex we want to switch from bash to xml (for |
| 13 |
whatever reason), we could rename from *.ebuild to *.xbuild. |
| 14 |
|
| 15 |
> But yeah, to be honest, you're right that my original "as long as |
| 16 |
> ebuilds stay bash" was a bit optimistic: it was assuming there would |
| 17 |
> be no decision of changing that rule as long as there would be no good |
| 18 |
> reason for it (like a switch to xml or whatever other not-bash |
| 19 |
> format). |
| 20 |
|
| 21 |
To 2: it might be acceptable to have it encoded into the filename. |
| 22 |
|
| 23 |
To 3 (and 2): Thomas++ |
| 24 |
|
| 25 |
> I still think that changing file names when absolutly required |
| 26 |
> (switching from "EAPI=foo" to "eapi foo", or moving it elsewhere, or |
| 27 |
> switching to xml, etc.) is less disturbing than changing it for every |
| 28 |
> single new EAPI. It's not because one new extension may not be |
| 29 |
> eternally enough that we should introduce an infinity right now. |
| 30 |
|
| 31 |
To 4: we agree that this never will be encoded in the filename ;) |
| 32 |
|
| 33 |
|
| 34 |
Just another bit of brainstorm (forget it if too broken): |
| 35 |
|
| 36 |
What if we do not start with "EAPI=1" variable, but "eapi 1" function |
| 37 |
immediately ? |
| 38 |
|
| 39 |
I could think of several implementations to let PM detect EAPI: |
| 40 |
|
| 41 |
*) Given it is the first bash-command in the ebuild: |
| 42 |
Just 'echo' the required EAPI and exit while PM is in "look-for-eapi" |
| 43 |
mode (remember 'eapi' function is part of PM, or profile.bashrc as |
| 44 |
fallback for ancient PM). |
| 45 |
|
| 46 |
*) As 'eapi' being a bash function, it could *migrate* the |
| 47 |
bash-environment from the PM's default EAPI to the given one - or just |
| 48 |
spit "cannot migrate EAPI from A to B"... |
| 49 |
|
| 50 |
*) Or just spit a message "update your PM" (from profile.bashrc) ... |
| 51 |
|
| 52 |
Just want to show that using 'eapi-function' should be more flexible |
| 53 |
than 'EAPI-variable', and thus will not be subject to change too often |
| 54 |
and require 2) (see above). |
| 55 |
|
| 56 |
/haubi/ |
| 57 |
-- |
| 58 |
Michael Haubenwallner |
| 59 |
Gentoo on a different level |
| 60 |
|
| 61 |
-- |
| 62 |
gentoo-dev@g.o mailing list |
Archives