Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Donnie Berkholz <dberkholz@g.o>
Subject: Re: new `usex` helper
Date: Wed, 21 Sep 2011 08:11:56 -0500
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
Attachment:
pgpEfDk4djGXT.pgp (PGP signature)
Replies:
Re: new `usex` helper
-- Alec Warner
References:
Re: new `usex` helper
-- Donnie Berkholz
Re: new `usex` helper
-- Brian Harring
Re: new `usex` helper
-- Donnie Berkholz
Re: new `usex` helper
-- Brian Harring
Re: new `usex` helper
-- Donnie Berkholz
Re: new `usex` helper
-- Brian Harring
Re: new `usex` helper
-- Donnie Berkholz
Re: new `usex` helper
-- Brian Harring
Re: new `usex` helper
-- Donnie Berkholz
Re: new `usex` helper
-- Brian Harring
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: new `usex` helper
Next by thread:
Re: new `usex` helper
Previous by date:
Re: Re: euscan proof of concept (like debian's uscan)
Next by date:
Re: git-2: a bunch of patches to review


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.