1 |
On Thu, 08 Mar 2012 13:37:09 -0500 |
2 |
Michael Orlitzky <michael@××××××××.com> wrote: |
3 |
> > It probably should. Although in the early days the model for ebuilds |
4 |
> > was that they were scripts that were "executed", nowadays there's so |
5 |
> > much support required that it's better to think of ebuilds as being |
6 |
> > data. If you did have a /usr/bin/eapi5, it would have to be |
7 |
> > implemented as something that invoked the package manager, not as a |
8 |
> > direct interpreter. |
9 |
> |
10 |
> Fair enough, but aren't you arguing the opposite point with Zac? If |
11 |
> ebuilds are data, fine, we write EAPI=4 somewhere and be done with |
12 |
> it. Anything not having that format is out-of-spec. |
13 |
|
14 |
The problem is that right now there's no way to determine the format of |
15 |
the data until you already know the format of the data. We hack around |
16 |
this by not allowing "drastic" format changes, where "drastic" includes |
17 |
"using things in newer versions of bash" and "not adding new global |
18 |
scope commands". |
19 |
|
20 |
The question under discussion is whether we a) keep "what format the |
21 |
data is in" as being part of the data, but impose some strange and |
22 |
arbitrary conditions on it, b) make a one-time change to have some kind |
23 |
of 'header' inside the file describing its format that isn't really part |
24 |
of the data itself, or c) admit that GLEP 55 already solved the problem |
25 |
and we might as well just fix the issue properly once and for all, even |
26 |
if GLEP 55's author is considered by some to be one of Satan's little |
27 |
minions. |
28 |
|
29 |
> If they're code, they're code, and we need to execute them somehow. |
30 |
|
31 |
The notion of "execute them somehow" that's used doesn't fit in with |
32 |
the #! interpreter model. You aren't executing ebuilds via an |
33 |
interpreter. You're performing an action that involves using the data |
34 |
and code in an ebuild multiple times and in multiple different ways, |
35 |
and that may also involve doing the same to an installed package that |
36 |
is being replaced. |
37 |
|
38 |
-- |
39 |
Ciaran McCreesh |