Joe Peterson wrote:
>>> But what users *really* don't care about is EAPIs, and this GLEP would
>>> expose that technical detail to them in a very blatent way.
>> Anyone who cares about ebuilds at a file level has to care about EAPIs.
> 
> Not really.  A typical user does not need to know about EAPIs at all,
> but he might want to peruse the portage tree to look for ebuilds.  He
> might also want to grep for KEYWORDS or whatever.

If the user knows that keywords are set by the KEYWORDS variable, then
she must be familiar with the EAPI. The meaning of the KEYWORDS variable
is defined by the EAPI.

>>> Along those lines, as I've said before, migrating to a new extension,
>>> *one-time*, as a solution to this, although not optimal, would be far
>>> more satisfactory than introducing a series of ever-changing
>>> extensions.
>> No it won't. It means future EAPIs will be restricted to some
>> particular source format.
> 
> I assume you mean that EAPI needs to be in the file - again, is this
> bad?  Many file formats specify a file format version as part of the file.

Sure. If current EAPI specified that a sequence of four bytes starting
at offset  0x10 is a little-endian magic number that is used to identify
an EAPI, that'd be all we want. However, current format definition is
rather complex; there's nothing as simple as "read several bytes at some
offset and use them".

Cheers,
-jkt
-- 
gentoo-dev@g.o mailing list