1 |
I've got a very rough draft of what EAPI 3 might end up looking like, |
2 |
based upon discussion: |
3 |
|
4 |
http://github.com/ciaranm/pms/tree/eapi-3 |
5 |
|
6 |
Note that I will probably rebase and modifying the branch quite a bit, |
7 |
so if you don't know how to deal with that when using git, don't track |
8 |
it. |
9 |
|
10 |
It should be one commit per feature, which makes it fairly easy to |
11 |
remove anything that ends up not making it, and very easy to see what's |
12 |
proposed, which currently looks like this: |
13 |
|
14 |
* Introduce eapi 3 |
15 |
* Rework tables for EAPI 3. |
16 |
* EAPI 3 has pkg_pretend. |
17 |
* EAPI 3 supports slot operator dependencies |
18 |
* EAPI 3 has use dependency defaults |
19 |
* PROPERTIES, DEFINED_PHASES mandatory in EAPI 3 |
20 |
* EAPI 3 has a default src_install |
21 |
* EAPI 3 has controllable compression and docompress |
22 |
* EAPI 3 has dodoc -r |
23 |
* EAPI 3 requires doins support for symlinks |
24 |
* EAPI 3 bans || ( use? ( ... ) ) |
25 |
* dohard and dosed banned in EAPI 3 |
26 |
* doinclude, newinclude for EAPI 3 |
27 |
* EAPI 3 supports .xz, .tar.xz |
28 |
* EAPI 3 has more econf arguments |
29 |
* EAPI 3 supports pkg_info on installed packages |
30 |
* USE is stricter in EAPI 3 |
31 |
* Note that (+) won't work on USE_EXPAND etc things |
32 |
* AA, KV gone in EAPI 3 |
33 |
|
34 |
Still to work out: |
35 |
|
36 |
* The exact details for the new USE restrictions. In particular, do we |
37 |
want IUSE_IMPLICIT? We'll also need an accurate list of all |
38 |
possible values for things like LINGUAS. |
39 |
|
40 |
* The [use(+)] thing. For various really pesky reasons, there's no way |
41 |
things like [video_cards_radeon(+)] can be expected to work when |
42 |
applied against EAPIs before 3, but it can be made to work if we know |
43 |
it'll only ever be applied against things with EAPI 3 or later. Is it |
44 |
easier to just say it's never allowed, though? |
45 |
|
46 |
* What's a doexample? |
47 |
|
48 |
* What's default_src_install going to do? I've seen a load of |
49 |
variations. It looks like our choices are between things that ignore |
50 |
docs, making it largely worthless, or things that use a DOCS |
51 |
variable, which Donnie hates (despite making extensive use of such |
52 |
things himself in eclasses). |
53 |
|
54 |
* "Provide ebuilds a way to differentiate between updates and |
55 |
removals". I suggested REPLACING_VERSIONS and REPLACED_BY_VERSION, |
56 |
but I've not had any feedback on that. |
57 |
|
58 |
* "Utility commands, even the ones that aren't functions, should die.". |
59 |
Is Portage likely to be able to do this in the timeframe we're after? |
60 |
|
61 |
* "Calling unpack on an unrecognised extension should be fatal, unless |
62 |
--if-compressed is specified.". There've been questions on this, but |
63 |
no obvious outrage. Is this in or out? |
64 |
|
65 |
* I've left out killing off dohtml. Was a decision reached on that? |
66 |
|
67 |
* RDEPEND=DEPEND is still in. Again, was a decision reached? |
68 |
|
69 |
* xz is in, but do we really want to do that when there appears to be |
70 |
nothing stable that can deal with xz? lzma going in was a mistake |
71 |
caused by people being too eager here in exactly the same way they |
72 |
were for making Portage handle xz... |
73 |
|
74 |
* Am I to take it src_test is to remain in its current worthless state? |
75 |
|
76 |
I've probably missed some more things, but I don't know what they are, |
77 |
so if anyone can find any please list them. |
78 |
|
79 |
-- |
80 |
Ciaran McCreesh |