1 |
On Thu, 6 Sep 2012 01:11:45 -0700 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
|
4 |
> A compatibility hack that stacks them is strongly advisable; |
5 |
> something akin to the following: |
6 |
> |
7 |
> Literally, we do the following: |
8 |
> inherit() { |
9 |
> if eapi blah; then |
10 |
> local DEPEND PDEPEND RDEPEND |
11 |
> <usual saving/protection of DEPENDENCIES var> |
12 |
> else |
13 |
> <usual saving/protection of DEPEND/PDEPEND/RDEPEND vars> |
14 |
> fi |
15 |
> <normal sourcing machinery> |
16 |
> if eapi blah; then |
17 |
> local _deps=( ) _x |
18 |
> for _x in DEPENDENCIES DEPEND RDEPEND PDEPEND; do |
19 |
> [ -n "${!_x}" ] && deps+=( "${!_x}" ) |
20 |
> done |
21 |
> [ ${#deps} -ne 0 ] && DEPENDENCIES="${deps[*]}" |
22 |
> unset DEPEND RDEPEND PDEPEND _x _deps |
23 |
> <normal stacking/restoration of DEPENDENCIES rules> |
24 |
> else |
25 |
> <normal stacking/restoration of RDEPEND/PDEPEND/DEPEND> |
26 |
> fi |
27 |
> } |
28 |
> |
29 |
> Via that, we eclasses that are pure DEPENDENCIES eapi wise, just set |
30 |
> the DEPENDENCIES directly; those that have to support multiple eapi's |
31 |
> (aka, every fricking eclass that exists right now) can just use the |
32 |
> old form, shifting into the new form as things progress. |
33 |
|
34 |
If we decide to go with a such a hack, then we either have to support |
35 |
it indefinitely, or to decide to drop the support in some further EAPI. |
36 |
|
37 |
If we go for the latter, then it's just delaying the ugly conditional |
38 |
eclasses will have to suffer at some random point in the future. Well, |
39 |
maybe two eclasses less if we wait with it for an EAPI which will |
40 |
provide 'killer features' which will render the eclasses unusable with |
41 |
older EAPIs. And way, it will be a bit confusing to remember two switch |
42 |
points... |
43 |
|
44 |
If we go for the former... then some developers will ask: why eclasses |
45 |
and not ebuilds? Why? |
46 |
|
47 |
-- |
48 |
Best regards, |
49 |
Michał Górny |