1 |
On Wed, 25 Feb 2009 16:02:46 -0800 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
> Bullshit. First invocation of the ebuild, that means it can do |
4 |
> whatever it wants to the environment- literally swapping in the EAPI |
5 |
> environment right then/there. Auto inherits, changing the inherit |
6 |
> mechanism, everything (this includes shopt adjustments). |
7 |
> |
8 |
> Not even sure why you're arguing that one, but back it up w/ examples |
9 |
> if you want to continue that line of FUD. |
10 |
|
11 |
You can do that on a variable assignment too, with all the same |
12 |
implications as having it as a function, and a slightly less horrible |
13 |
upgrade path. |
14 |
|
15 |
> > Global scope die is very very messy. This leaks out to users in the |
16 |
> > form of horrible messages that make the user think something's badly |
17 |
> > broken. |
18 |
> |
19 |
> One would think "upgrade your manager" would be... self explanatory. |
20 |
> Regardless, spelling it out- the user visible barf is only visible on |
21 |
> existant managers. |
22 |
> |
23 |
> For any manager supporting eapi>2 (thus having the function), the |
24 |
> function can exist out cleanly (no stderr complaints) from sourcing |
25 |
> at that point without issue. |
26 |
|
27 |
Which is a "wait a year or more" thing... If you do it with a variable |
28 |
instead of a function, you can at least roll out EAPI 3 (without any |
29 |
global scope changes, but with the stricter "stop on setting an |
30 |
unsupported EAPI" requirement) without the wait. |
31 |
|
32 |
> Every proposal has uglyness- g55 for example doesn't give the user |
33 |
> any indication that they're not seeing ebuilds due to EAPI (in other |
34 |
> words loss of functionality that exists now). |
35 |
|
36 |
Given you're a proponent of not showing users things that're merely |
37 |
masked... |
38 |
|
39 |
-- |
40 |
Ciaran McCreesh |