Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Rich Freeman]

On Mon, Mar 12, 2012 at 6:12 AM, Kent Fredric <kentfredric@×××××.com> wrote:
>
> There's the obvious case of compiled-binaries where that might not be
> possible, but thats definately strawman stuff and I wouldn't support
> that sort of nonsense anyway. Compiled binaries for ebuilds can gtfo.
>

Why do I feel like a similar debate must have happened on some list
back when the SMTP message terminator was worked out?  The problem is
that we're running into is the use of in-band control information.

An advantage of sticking the EAPI in the filename is that it is
completely out-of-band.  Other options like an external file or POSIX
attributes have the same advantage (with the disadvantage that they
are harder to keep in-sync or support in general).

If you want to stick the EAPI inside the file then we have to go with
one of two routes:

1.  Make the file directly interpret-able by some existing tool like
bash, xml parsers, or (gtfo) ld-linux.so.  This requires making the
EAPI in-band info, and thus if the file format changes there is risk
that any existing code that interprets EAPIs could break, to the
degree that we weren't infinitely clever in designing the spec.

2.  Make the file require pre-processing before being fed to another
interpreter.  This breaks syntax-highlighting and such, and is
generally more of a pita.  However, this allows in-file EAPI info to
remain out-of-band.  An ebuild might be an xml file with EAPI and
other meta-data, and might contain sections that get ripped out and
handed over to bash, python, or ld-linux.so to the extent that you
want to be told to gtfo.

In my thinking the option with the fewest drawbacks and the greatest
extent of future-proofing is to go with GLEP 55 and stick it in the
filename.  Every filesystem and rsync tool handles filenames, they're
impossible to separate from file contents, and every interpreter out
there ignores them.

If we don't want to stick it in the filename then either we have to
decide that whatever we come up with could break, or that we really
have to change what ebuilds look like.

Rich