1 |
On 13-11-2009 12:43:25 +0100, Ulrich Mueller wrote: |
2 |
> In its November meeting [1], the council has unanimously expressed |
3 |
> support for this proposal [2]. |
4 |
> |
5 |
> However, there is need for additional discussion. From the council |
6 |
> meeting log I could extract the following open questions: |
7 |
> |
8 |
> 1. What are the implications for non-prefix devs and users? |
9 |
|
10 |
for devs: take note of EPREFIX, ED and EROOT, be aware what they mean |
11 |
and eventually, use them in the right way. This is not hard, since a |
12 |
simple script[3] based on some heuristics can do the work in 98% of the |
13 |
cases right. |
14 |
for users: not an single bit, unless they look inside ebuilds |
15 |
|
16 |
> 2. Should the Prefix team be allowed to do the necessary changes to |
17 |
> ebuilds themselves, or should it be done by the respective |
18 |
> maintainers? |
19 |
|
20 |
The Prefix team is the equivalent of an arch team, only handling a big |
21 |
bunch of arches [4]. Hence, keywording should be out of the question, |
22 |
and just allowed. Adding simple patches (to normal non-critical |
23 |
ebuilds) used to be allowed AFAIR, so I see that as ok too. In other |
24 |
words, like darkside mentioned, I see our activities like those of an |
25 |
arch team. |
26 |
|
27 |
> 3. Are there any backwards compatibility or upgrade path issues for |
28 |
> eclasses that must still accept EAPI 0 (where the new ED, EROOT, |
29 |
> and EPREFIX variables are not defined)? |
30 |
|
31 |
The backward and forward compatability is handled with conditional |
32 |
code like: |
33 |
use prefix || local ED=${D} |
34 |
or |
35 |
[[ -z ${ED} ]] && local ED=${D} |
36 |
|
37 |
Since Zac checked in yesterday blacklisting of EPREFIX, EROOT and ED in |
38 |
the main Portage branch, these variables hopefully soon become protected |
39 |
in the sense that an externally set ED does not result in weird |
40 |
behaviour of a Prefix aware eclass or ebuild when using the latter |
41 |
approach, which is true forward compatible. |
42 |
For your information, this was exactly what I asked for from the council. |
43 |
|
44 |
> 4. EAPI numbering: Would this simply be added as an additional |
45 |
> feature to EAPI 3? Or should we have an intermediate EAPI slot, |
46 |
> e.g. 2.1 or 3 (and current EAPI 3 renamed to 4 in the latter |
47 |
> case)? |
48 |
|
49 |
I don't care about this, but a fast EAPI is necessary to 1) rely on ED not |
50 |
coming from outside, and 2) since we're defining ED, EROOT and EPREFIX |
51 |
anyway, initialise ED and EROOT such that we don't need any conditional |
52 |
code in ebuilds at all (and can just use ED where necessary). |
53 |
|
54 |
> 5. Who is going to write the exact specification (PMS patch) for |
55 |
> this EAPI feature? |
56 |
|
57 |
We agreed that I/Prefix team will give this a shot. |
58 |
|
59 |
> 6. (Any question that I've missed?) |
60 |
|
61 |
I guess most additional questions go beyond, and actually address the |
62 |
real Prefix work, and its implications to Gentoo and many ebuilds, since |
63 |
we have to touch around 2300 ebuilds, most with trivial changes, some |
64 |
with heavy changes (think of the 32 patches that one needs to compile |
65 |
Python...) |
66 |
|
67 |
> Let's start the discussion now, in order to work out these details |
68 |
> before the next council meeting (December 7th). |
69 |
> |
70 |
> Ulrich |
71 |
> |
72 |
> [1] <http://www.gentoo.org/proj/en/council/meeting-logs/20091109.txt> |
73 |
> (topic was discussed from 21:32 to 22:11 in the log's timezone) |
74 |
> [2] <http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml> |
75 |
> |
76 |
|
77 |
[3] http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/scripts/eapify |
78 |
[4] http://stats.prefix.freens.org/keywords-packages.png |
79 |
|
80 |
-- |
81 |
Fabian Groffen |
82 |
Gentoo on a different level |