On Wed, 25 Feb 2009 16:24:45 -0800 Brian Harring <ferri...@gmail.com> 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
signature.asc
Description: PGP signature