Re: [gentoo-portage-dev] PATCH: initial EAPI awareness

[Brian Harring]

On Thu, Sep 01, 2005 at 10:27:44PM -0700, Zac Medico wrote:
> Paul de Vrieze wrote:
> >On Wednesday 31 August 2005 14:57, Brian Harring wrote:
> >
> >>Re: tagging EAPI at the top of a file, infra would probably shoot me for
> >>doing such- till a live, fully compatible and *roughly* equivalent parser
> >>is available, portage would have to do a bit of grepping, jacking up the
> >>regen times.
> >
> >
> >If in cache EAPI can be gotten from the cache. If not, I don't think it
> >matters where in the file EAPI occurs from the standpoint of getting it's
> >value. The only thing would be that in the future a fast EAPI parser could
> >be made that would just look at EAPI and get its version. I could easilly
> >write you such a parser.
>
> It is impossible write a parser for an unconstrained and unknown format
> that may exist in the future.  If we put a constraint on the format, in
> order to parse the EAPI, then we contradict our original goal (to
> unconstrain the format).
>
> A better approach IMO would be to store the EAPI in a separate file such as
> metadata.xml.  This would allow *absolute* flexibility in the "ebuild"
> format.  Portage would be able to select an appropriate parser with no need
> to examine the "ebuild" itself.
Disallows eclasses from ever setting eapi.

Like I've said, EAPI is ebuild specific.  Ebuild is a format; eapi 
defines revisions of it, in my mind a minor revision of the ebuild 1 
format.  Any form of loss of backwards compatability *should* be a 
different format, .ebuild2 for all I care.

Trying to use EAPI to allow for N different formats into one format is 
wrong from where I sit; you would need a container format for it, 
which ebuild wasn't designed for (nor is it easily extensible to be 
made so I posit).

EAPI's original specification was for handling addition of new funcs, 
different hooks in the ebuild; I prefer it remain as this.  The core 
rewrite is format agnostic, if a new format is defined (whether a 
massively managled version of ebuild or flat out new), it's a seperate 
format and should be handled via the core, not via ebuild specific 
package handling.

There's no reason a repository can't hold multiple formats internally; 
the capability is there, use that rather then trying to jam too much 
into EAPI, imo at least.
~harring