1 |
Bit curious what folks opinions are re: conversion of eapi |
2 |
requirements into a function, instead of a var. Essentially, |
3 |
currently- |
4 |
|
5 |
""" |
6 |
#my ebuild. |
7 |
EAPI=1 |
8 |
inherit blah |
9 |
DEPEND=monkey |
10 |
|
11 |
funcs_and_such(){:;} |
12 |
|
13 |
""" |
14 |
|
15 |
pros: |
16 |
* simple, and was enough to get EAPI off the ground w/out massive |
17 |
fighting (at least not WW3 level fighting) |
18 |
* works fine for metadata key level changes, function changes, etc. |
19 |
I'm aware folks have stated "if DEPENDS changes, it won't be able to |
20 |
handle it"- they're frankly wrong, they're confusing that post |
21 |
sourcing EAPI is checked, *then* if EAPI is supported the metadata is |
22 |
handled, else the manager is signaled that an unknown eapi was |
23 |
encountered (essentially). Continuing... |
24 |
|
25 |
cons: |
26 |
* EAPI var must be set effectively before any invocations occur. |
27 |
* global scope invocations (inherit) must be eapi aware; |
28 |
* future additions to global scope invocations (say elib) will result |
29 |
in an error spat by bash ("elib wasn't found"). |
30 |
* bash specific (which personally is fine to me, an ebuild is bash). |
31 |
* doesn't address versioning changes. |
32 |
|
33 |
Converting it into |
34 |
|
35 |
""" |
36 |
#my ebuild. |
37 |
eapi 1 |
38 |
inherit blah |
39 |
DEPEND=monkey |
40 |
|
41 |
funcs_and_such(){:;} |
42 |
|
43 |
""" |
44 |
|
45 |
with eapi effectively being |
46 |
|
47 |
eapi() { |
48 |
if [ "$1" == 1 ] || [ "$1" == 0 ]; |
49 |
return # we know this eapi, can handle it |
50 |
fi |
51 |
die "unsupported eapi $1" |
52 |
} |
53 |
|
54 |
pros: |
55 |
* same benefits as preexisting var approach. |
56 |
* via conversion to invocation instead of var setting (which is |
57 |
untrappable), it's possible to bail the rest of the sourcing, thus |
58 |
preventing any error msgs for unknown global invocations (elib fex). |
59 |
* easy to shoehorn in for any profile.bashrc compliant manager |
60 |
(portage/pkgcore); realize paludis is left out here (via it |
61 |
intentionally being left out of PMS atm by ciaran), but |
62 |
profile.bashrc *is* used by ebuild devs, thus it's a viable course (I |
63 |
don't see profile.bashrc ever going away basically). |
64 |
|
65 |
cons: |
66 |
* must be the first invocation. |
67 |
* bash specific (again, ebuild is bash, new format can do things |
68 |
w/out having to worry about backwards compatibility). |
69 |
* doesn't address versioning changes. |
70 |
|
71 |
|
72 |
Basically, the proposal is an minor tweak of existing support- it has |
73 |
the benefit of avoiding the filename complaints from folks and |
74 |
addressing the usual "global scope invocation will breakzor in later |
75 |
versions" complaint from paludis folk. |
76 |
|
77 |
It doesn't particularly provide for people shoving new versioning |
78 |
components in, but frankly that's fine due to the mess having |
79 |
versioning rules bound to EAPI would entail. |
80 |
|
81 |
After comments from folks, although if a responder is going to state |
82 |
"filename is better!" skip it please, I already pointed out the diffs |
83 |
(meaning bluntly, kindly skip repeating what has already been said). |
84 |
|
85 |
Cheers |
86 |
~harring |