Gentoo Archives: gentoo-portage-dev

From: Paul de Vrieze <pauldv@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] PATCH: initial EAPI awareness
Date: Fri, 02 Sep 2005 08:55:38
In Reply to: Re: [gentoo-portage-dev] PATCH: initial EAPI awareness by Brian Harring
1 On Friday 02 September 2005 08:04, Brian Harring wrote:
2 >
3 > Like I've said, EAPI is ebuild specific. Ebuild is a format; eapi
4 > defines revisions of it, in my mind a minor revision of the ebuild 1
5 > format. Any form of loss of backwards compatability *should* be a
6 > different format, .ebuild2 for all I care.
8 The new proposed format loses backwards compatibility. If there is
9 backwards compatibility no new format or api version is needed. EAPI
10 should work on the python level, not only on the level.
12 > Trying to use EAPI to allow for N different formats into one format is
13 > wrong from where I sit; you would need a container format for it,
14 > which ebuild wasn't designed for (nor is it easily extensible to be
15 > made so I posit).
17 No it would state that the eclass is 100% compatible with both by the
18 formats overlapping and the ebuild not threading outside the overlapped
19 area. Take for an example many simple kde applications. Those use the kde
20 eclass to do all the work and only contain a skeleton of variables
21 themselves. These ebuilds are compatible with both the current as the
22 proposed new API. When marked so, they could be used as EAPI=1 as soon as
23 the kde eclass is ported to EAPI=1. Similarly many eclasses do not
24 provide src_compile, and as such are compatible with both EAPI versions.
26 > EAPI's original specification was for handling addition of new funcs,
27 > different hooks in the ebuild; I prefer it remain as this. The core
28 > rewrite is format agnostic, if a new format is defined (whether a
29 > massively managled version of ebuild or flat out new), it's a seperate
30 > format and should be handled via the core, not via ebuild specific
31 > package handling.
33 EAPI now is going to be used for the above. It can however with very
34 little effort be made such that future ebuild format revisions are
35 possible. Also don't be mistaken that splitting out configure and make
36 stages do need support from the python part.
38 >
39 > There's no reason a repository can't hold multiple formats internally;
40 > the capability is there, use that rather then trying to jam too much
41 > into EAPI, imo at least.
43 How would you suggest to do this then. The ebuilds/eclasses are completely
44 the same except for their EAPI definition. They also have the same
45 (file)name. And that is not counting the fact that two files containing
46 the same is bad design as there will allways be an issue of one file
47 being updated and the other not.
49 Paul
51 --
52 Paul de Vrieze
53 Gentoo Developer
54 Mail: pauldv@g.o
55 Homepage:


Subject Author
Re: [gentoo-portage-dev] PATCH: initial EAPI awareness Brian Harring <ferringb@g.o>