Gentoo Archives: gentoo-portage-dev

From: Brian Harring <ferringb@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
Date: Fri, 02 Sep 2005 06:06:07
Message-Id: 20050902060453.GD8478@nightcrawler
In Reply to: Re: [gentoo-portage-dev] PATCH: initial EAPI awareness by Zac Medico
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.
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.
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).
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.
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


Subject Author
Re: [gentoo-portage-dev] PATCH: initial EAPI awareness Zac Medico <zmedico@×××××.com>
Re: [gentoo-portage-dev] PATCH: initial EAPI awareness Paul de Vrieze <pauldv@g.o>