On Wed, 25 Feb 2009 16:24:45 -0800
Brian Harring <ferringb@...> wrote:
> > You can do that on a variable assignment too, with all the same
> > implications as having it as a function, and a slightly less
> > horrible upgrade path.
> 
> You're contradicting your own statements.  Pkg level eclasses (if 
> reusing inherit) would explode 'in a user visible manner' if using
> var only.

No, if we're shoving retroactive changes into existing EAPIs (as would
be done for making eapi a function), we could instead say "EAPI must be
assigned to only once". That has *exactly* the same implications as
having it as a function, except that the upgrade path is cleaner
because there's no need for the horrid global scope die to work around
existing package managers.

> > Which is a "wait a year or more" thing... If you do it with a
> > variable instead of a function, you can at least roll out EAPI 3
> > (without any global scope changes, but with the stricter "stop on
> > setting an unsupported EAPI" requirement) without the wait.
> 
> There is no reason to wait a year let alone wait for EAPI3 to be 
> defined.  The eapi function could be added now in preparation (thus 
> killing the user visible pukage), regardless of eapi 3's timeline.
> 
> The die exists strictly to be thorough about stragglers.

But there's no need for the die if you do it on a variable instead of a
function.

> > > Every proposal has uglyness- g55 for example doesn't give the user
> > > any indication that they're not seeing ebuilds due to EAPI (in
> > > other words loss of functionality that exists now).
> > 
> > Given you're a proponent of not showing users things that're merely
> > masked...
> 
> Say what you want; g55 still has the flaw.

Any sane package manager can, immediately upon a new EAPI being
defined, do a stable release updated with minimal information about the
new EAPI to enable it to show up as being there but not supported, even
if full support needs a new major version and lots of ~arch testing
time.

-- 
Ciaran McCreesh