Gentoo Archives: gentoo-dev

From: Donnie Berkholz <dberkholz@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] new `usex` helper
Date: Wed, 21 Sep 2011 13:12:46
Message-Id: 20110921131156.GA3640@comet
In Reply to: Re: [gentoo-dev] new `usex` helper by Brian Harring
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:


Subject Author
Re: [gentoo-dev] new `usex` helper Alec Warner <antarus@g.o>