1 |
On Thu, Feb 26, 2009 at 12:11:04AM +0000, Ciaran McCreesh wrote: |
2 |
> On Wed, 25 Feb 2009 16:02:46 -0800 |
3 |
> Brian Harring <ferringb@×××××.com> wrote: |
4 |
> > Bullshit. First invocation of the ebuild, that means it can do |
5 |
> > whatever it wants to the environment- literally swapping in the EAPI |
6 |
> > environment right then/there. Auto inherits, changing the inherit |
7 |
> > mechanism, everything (this includes shopt adjustments). |
8 |
> > |
9 |
> > Not even sure why you're arguing that one, but back it up w/ examples |
10 |
> > if you want to continue that line of FUD. |
11 |
> |
12 |
> You can do that on a variable assignment too, with all the same |
13 |
> implications as having it as a function, and a slightly less horrible |
14 |
> upgrade path. |
15 |
|
16 |
You're contradicting your own statements. Pkg level eclasses (if |
17 |
reusing inherit) would explode 'in a user visible manner' if using var |
18 |
only. |
19 |
|
20 |
While the above wasn't FUD, definitely was misinfo. Be consistant |
21 |
please. |
22 |
|
23 |
|
24 |
> > > Global scope die is very very messy. This leaks out to users in the |
25 |
> > > form of horrible messages that make the user think something's badly |
26 |
> > > broken. |
27 |
> > |
28 |
> > One would think "upgrade your manager" would be... self explanatory. |
29 |
> > Regardless, spelling it out- the user visible barf is only visible on |
30 |
> > existant managers. |
31 |
> > |
32 |
> > For any manager supporting eapi>2 (thus having the function), the |
33 |
> > function can exist out cleanly (no stderr complaints) from sourcing |
34 |
> > at that point without issue. |
35 |
> |
36 |
> Which is a "wait a year or more" thing... If you do it with a variable |
37 |
> instead of a function, you can at least roll out EAPI 3 (without any |
38 |
> global scope changes, but with the stricter "stop on setting an |
39 |
> unsupported EAPI" requirement) without the wait. |
40 |
|
41 |
There is no reason to wait a year let alone wait for EAPI3 to be |
42 |
defined. The eapi function could be added now in preparation (thus |
43 |
killing the user visible pukage), regardless of eapi 3's timeline. |
44 |
|
45 |
The die exists strictly to be thorough about stragglers. |
46 |
|
47 |
|
48 |
> > Every proposal has uglyness- g55 for example doesn't give the user |
49 |
> > any indication that they're not seeing ebuilds due to EAPI (in other |
50 |
> > words loss of functionality that exists now). |
51 |
> |
52 |
> Given you're a proponent of not showing users things that're merely |
53 |
> masked... |
54 |
|
55 |
Say what you want; g55 still has the flaw. |
56 |
|
57 |
~harring |