1 |
On Thu, 20 Dec 2007 09:43:59 +0000 (UTC) |
2 |
Duncan <1i5t5.duncan@×××.net> wrote: |
3 |
> > Because a) a future EAPI might want to change EAPI into a function |
4 |
> > rather than a variable, b) there are a zillion ways of setting a |
5 |
> > variable in bash and people already use all of them and c) |
6 |
> > introducing new weird format requirements is silly. |
7 |
> |
8 |
> So you're proposing putting the function into the filename? |
9 |
|
10 |
No, I'm saying that the data goes into the filename. |
11 |
|
12 |
> As he stated, the only credible reason (so far given) bash must be |
13 |
> used to parse EAPI is if it's dynamic, say a function, and that won't |
14 |
> work so well in a filename either. |
15 |
|
16 |
No no no. Bash is the only thing that can parse bash. Ebuilds are bash. |
17 |
|
18 |
> Thus, putting EAPI in the filename pretty much eliminates the |
19 |
> possibility of it being a function, and we're back to the original |
20 |
> question, instead of a GLEP allowing it in the filename, why not a |
21 |
> GLEP specifying the format of that single variable in the file |
22 |
> contents well enough to parse without bash? |
23 |
|
24 |
Because that would be introducing a new, non-extensible, inflexible |
25 |
requirement upon the content of ebuilds, and the goal of EAPI is to |
26 |
avoid doing exactly that. |
27 |
|
28 |
-- |
29 |
Ciaran McCreesh |