On Thu, 08 Mar 2012 13:37:09 -0500 Michael Orlitzky <mich...@orlitzky.com> 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 scope commands". 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 minions. > 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. -- Ciaran McCreesh
signature.asc
Description: PGP signature
