1 |
On Thu, Sep 01, 2005 at 10:27:44PM -0700, Zac Medico wrote: |
2 |
> Paul de Vrieze wrote: |
3 |
> >On Wednesday 31 August 2005 14:57, Brian Harring wrote: |
4 |
> > |
5 |
> >>Re: tagging EAPI at the top of a file, infra would probably shoot me for |
6 |
> >>doing such- till a live, fully compatible and *roughly* equivalent parser |
7 |
> >>is available, portage would have to do a bit of grepping, jacking up the |
8 |
> >>regen times. |
9 |
> > |
10 |
> > |
11 |
> >If in cache EAPI can be gotten from the cache. If not, I don't think it |
12 |
> >matters where in the file EAPI occurs from the standpoint of getting it's |
13 |
> >value. The only thing would be that in the future a fast EAPI parser could |
14 |
> >be made that would just look at EAPI and get its version. I could easilly |
15 |
> >write you such a parser. |
16 |
> |
17 |
> It is impossible write a parser for an unconstrained and unknown format |
18 |
> that may exist in the future. If we put a constraint on the format, in |
19 |
> order to parse the EAPI, then we contradict our original goal (to |
20 |
> unconstrain the format). |
21 |
> |
22 |
> A better approach IMO would be to store the EAPI in a separate file such as |
23 |
> metadata.xml. This would allow *absolute* flexibility in the "ebuild" |
24 |
> format. Portage would be able to select an appropriate parser with no need |
25 |
> to examine the "ebuild" itself. |
26 |
Disallows eclasses from ever setting eapi. |
27 |
|
28 |
Like I've said, EAPI is ebuild specific. Ebuild is a format; eapi |
29 |
defines revisions of it, in my mind a minor revision of the ebuild 1 |
30 |
format. Any form of loss of backwards compatability *should* be a |
31 |
different format, .ebuild2 for all I care. |
32 |
|
33 |
Trying to use EAPI to allow for N different formats into one format is |
34 |
wrong from where I sit; you would need a container format for it, |
35 |
which ebuild wasn't designed for (nor is it easily extensible to be |
36 |
made so I posit). |
37 |
|
38 |
EAPI's original specification was for handling addition of new funcs, |
39 |
different hooks in the ebuild; I prefer it remain as this. The core |
40 |
rewrite is format agnostic, if a new format is defined (whether a |
41 |
massively managled version of ebuild or flat out new), it's a seperate |
42 |
format and should be handled via the core, not via ebuild specific |
43 |
package handling. |
44 |
|
45 |
There's no reason a repository can't hold multiple formats internally; |
46 |
the capability is there, use that rather then trying to jam too much |
47 |
into EAPI, imo at least. |
48 |
~harring |