1 |
I'd like to propose a new metadata variable called DEFINED_PHASES. Like |
2 |
INHERITED, it will be generated by the package manager rather than by a |
3 |
combination of explicit ebuild and eclass variables. |
4 |
|
5 |
The DEFINED_PHASES variable is for package manager use; it may or may |
6 |
not be exported to the ebuild, and must not be used or set in any way by |
7 |
ebuilds. The DEFINED_PHASES proposal has (almost -- see below) no |
8 |
developer-visible effects, other than reserving a variable name. |
9 |
|
10 |
The name DEFINED_PHASES is currently only for convenience, since the |
11 |
metadata cache format uses fixed positions rather than a key=value |
12 |
format, but this may change in the future. In flat metadata cache, |
13 |
DEFINED_PHASES shall be line 17. |
14 |
|
15 |
The DEFINED_PHASES variable will contain a space separated arbitrarily |
16 |
ordered list of phase names. A phase name is listed in DEFINED_PHASES if |
17 |
and only if the ebuild or an eclass used by that ebuild provides an |
18 |
implementation of that phase's phase function. For example, the current |
19 |
value for app-editors/vim-7.2.021 would be (possibly not in this order): |
20 |
|
21 |
DEFINED_PHASES="setup unpack compile install test postinst postrm" |
22 |
|
23 |
If an ebuild uses the defaults for every single phase, rather than |
24 |
defining a blank DEFINED_PHASES, the package manager shall set it to the |
25 |
string "-". This will let the package manager tell the difference |
26 |
between "this metadata was generated by an old package manager" and |
27 |
"this ebuild uses defaults for everything". |
28 |
|
29 |
Support for DEFINED_PHASES shall be optionally retroactively added to |
30 |
all existing EAPIs. Package managers are not required to generate it, |
31 |
and package managers may not assume its existence. Future EAPIs may make |
32 |
DEFINED_PHASES mandatory. |
33 |
|
34 |
Having DEFINED_PHASES upfront is useful in a number of ways to the |
35 |
package manager: |
36 |
|
37 |
* It lets the package manager avoid having to run phases that have a "do |
38 |
nothing" default and that aren't defined by the ebuild. This is |
39 |
currently a fairly minor issue, but in the future if we start using |
40 |
src_fetch_extra (bug 249086) or pkg_pretend it makes quite a bit of |
41 |
difference. |
42 |
|
43 |
* It lets the package manager parallelise pkg_* functions in many |
44 |
situations. |
45 |
|
46 |
* It lets the package manager avoid having to go to 'interactive' mode |
47 |
for every phase of PROPERTIES=interactive ebuilds. |
48 |
|
49 |
There is one subtle implication of this proposal: it means the phases |
50 |
defined by an ebuild must now be metadata-invariant. So the following is |
51 |
remains legal: |
52 |
|
53 |
if [[ ${EAPI} == 2 ]] ; then |
54 |
src_configure() { |
55 |
blah |
56 |
} |
57 |
fi |
58 |
|
59 |
But this goes from being "probably illegal, but might work by fluke" to |
60 |
"definitely illegal": |
61 |
|
62 |
if use foo ; then |
63 |
src_configure() { |
64 |
blah |
65 |
} |
66 |
fi |
67 |
|
68 |
This is of course a good thing. |
69 |
|
70 |
-- |
71 |
Ciaran McCreesh |