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