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
pgpG3l5aSg1zX.pgp
Description: PGP signature
