1 |
On 09-10-2008 19:15:26 +0100, Ciaran McCreesh wrote: |
2 |
> On Thu, 9 Oct 2008 19:46:55 +0200 |
3 |
> Fabian Groffen <grobian@g.o> wrote: |
4 |
> > Currently in Prefix we implemented EAPI as being a set of tokens that |
5 |
> > are orthogonal to each other. In other words, while 0, 1 and 2 are |
6 |
> > mutual exclusive, "prefix" can be applied to 0, 1, or 2. The result |
7 |
> > is something like EAPI="prefix 1". Of course with this approach the |
8 |
> > recent introduction of EAPI=2, resulted in a problem with eclasses |
9 |
> > that do a blind check on the EAPI variable to be e.g. 2. |
10 |
> |
11 |
> EAPI's defined as being a single value because mixing between EAPIs is |
12 |
> in general impossible. For example, I'm guessing prefix might need to |
13 |
> do something to econf / the default src_compile/configure functions at |
14 |
> some point, so it's not really truly independent. |
15 |
|
16 |
While that is true, currently Prefix is designed in such a way that |
17 |
an empty offset results in a fully "backwards" compatible Portage. |
18 |
|
19 |
> Is there anything stopping you from formalising your specification of |
20 |
> what you need? (The PMS team can probably help with the 'writing formal' |
21 |
> bit if necessary, given an informal description.) Could it be done in |
22 |
> such a way that non-prefix package managers can do minimal support to |
23 |
> get the current /usr behaviour, whilst optionally implementing |
24 |
> everything else? If this is the case, the best route's probably to get |
25 |
> the whole thing into the next EAPI, start using that EAPI for all your |
26 |
> overlay packages and persuade people to include the necessary prefixy |
27 |
> things in main-tree eclasses (which they should, once said EAPI is |
28 |
> Council approved). |
29 |
|
30 |
A problem I have with requiring a "next" EAPI for each ebuild, is that |
31 |
Prefix requires all base-system ebuilds to be "Prefix compatible". |
32 |
However, this category of ebuilds requires being conservative with EAPI |
33 |
requirements. |
34 |
|
35 |
I once started on an attempt to document the stuff[1], but it's pretty |
36 |
verbose, and it misses the necessary informal definitions of in |
37 |
particular chapter [2]. |
38 |
|
39 |
> > Something that was raised in previous discussions was that maybe the |
40 |
> > Prefix extensions don't need an EAPI in itself, but that an ebuild has |
41 |
> > to be marked as Prefix-ready through e.g. the recently proposed |
42 |
> > PROPERTIES variable, (a horrible hack) in KEYWORDS, or a newly to be |
43 |
> > added variable. |
44 |
> |
45 |
> What's the scope of the changes? I think it'd be easiest to discuss |
46 |
> this if you posted an informal summary describing the differences in |
47 |
> terms of which bits of PMS are affected. |
48 |
|
49 |
[2] sums it up for as much as I can recall for the moment, the |
50 |
non-privileged stuff is supposed to be separate, but its use is |
51 |
inherently related to offset installations. Our overlay[3] contains |
52 |
enough material to get an idea of what it looks like in practise. If |
53 |
you want specific pointers, I can give you them. |
54 |
|
55 |
|
56 |
[1] http://dev.gentoo.org/~grobian/gleps/glep-prefix.html |
57 |
[2] http://dev.gentoo.org/~grobian/gleps/glep-prefix.html#ebuild-changes-in-prefix |
58 |
[3] http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay |
59 |
|
60 |
-- |
61 |
Fabian Groffen |
62 |
Gentoo on a different level |