1 |
On Wed, 25 Feb 2009 16:24:45 -0800 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
> > You can do that on a variable assignment too, with all the same |
4 |
> > implications as having it as a function, and a slightly less |
5 |
> > horrible upgrade path. |
6 |
> |
7 |
> You're contradicting your own statements. Pkg level eclasses (if |
8 |
> reusing inherit) would explode 'in a user visible manner' if using |
9 |
> var only. |
10 |
|
11 |
No, if we're shoving retroactive changes into existing EAPIs (as would |
12 |
be done for making eapi a function), we could instead say "EAPI must be |
13 |
assigned to only once". That has *exactly* the same implications as |
14 |
having it as a function, except that the upgrade path is cleaner |
15 |
because there's no need for the horrid global scope die to work around |
16 |
existing package managers. |
17 |
|
18 |
> > Which is a "wait a year or more" thing... If you do it with a |
19 |
> > variable instead of a function, you can at least roll out EAPI 3 |
20 |
> > (without any global scope changes, but with the stricter "stop on |
21 |
> > setting an unsupported EAPI" requirement) without the wait. |
22 |
> |
23 |
> There is no reason to wait a year let alone wait for EAPI3 to be |
24 |
> defined. The eapi function could be added now in preparation (thus |
25 |
> killing the user visible pukage), regardless of eapi 3's timeline. |
26 |
> |
27 |
> The die exists strictly to be thorough about stragglers. |
28 |
|
29 |
But there's no need for the die if you do it on a variable instead of a |
30 |
function. |
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 |
34 |
> > > other 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 |
> Say what you want; g55 still has the flaw. |
40 |
|
41 |
Any sane package manager can, immediately upon a new EAPI being |
42 |
defined, do a stable release updated with minimal information about the |
43 |
new EAPI to enable it to show up as being there but not supported, even |
44 |
if full support needs a new major version and lots of ~arch testing |
45 |
time. |
46 |
|
47 |
-- |
48 |
Ciaran McCreesh |