On 14:20 Tue 20 Sep     , Brian Harring wrote:
> On Sun, Sep 18, 2011 at 10:16:46PM -0500, Donnie Berkholz wrote:
> > OK, so the implication of what you're saying is that everything in 
> > eutils.eclass, base.eclass, toolchain-funcs.eclass, 
> > flag-o-matic.eclass, versionator.eclass, multilib.eclass, 
> > prefix.eclass, savedconfig.eclass, and maybe even linux-info.eclass 
> > and autotools{,-utils}.eclass should go into EAPI. All that stuff is 
> > pretty generally useful features.
> 
> Approximately... yes.  Some of that (base.eclass for example) is EAPI 
> compatibility that can't be folded in (would require retroactively 
> addding to an EAPI), others aren't yet stabilized (true multilib for 
> example, seems to still be under discussion), etc.
> 
> You get the jist.

Yep, and I'm completely on the opposite end of the spectrum. =)

> > > They should, but api compatibility of an eclass *can* be fluid- in 
> > > the past it was a locked API purely because of portage environment 
> > > saving issues.  That's been resolved, there isn't any strict 
> > > requirement that the eclass maintain API compat now.  You're 
> > > trying to rely on people doing best practices- for format building 
> > > blocks (use_with/usex/unpack/etc), that's not sane.
> > 
> > Which still pisses me off. It's like a shared library changing its 
> > API without bumping SONAME.
> 
> I think you're viewing this wrong; if we're talking about openssl 
> breaking API/ABI w/out bumping soname, sure.  It's one component that 
> is distributed alone, but consumed by others.  There is no way to 
> atomically deploy the new API at the same time as all of the consumers 
> being updated for it.
> 
> That is /not/ the case of gentoo-x86; eclasses for us are equivalent 
> to bundled libs.  Overlay stacking just makes it possible for a third 
> party component to reach in and use what is effectively an internal 
> lib.

Not really, because when you update a bundled lib you actually make your 
whole app compile with it. People change the APIs of eclasses and then 
just let every internal consumer (ebuilds in gentoo-x86) break. Maybe if 
we put the burden on the one who changed the API, like the Linux kernel 
model, it would bother me less.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com