public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Donnie Berkholz <dberkholz@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] new `usex` helper
Date: Wed, 21 Sep 2011 08:11:56 -0500	[thread overview]
Message-ID: <20110921131156.GA3640@comet> (raw)
In-Reply-To: <20110920212057.GA14344@beast>

[-- Attachment #1: Type: text/plain, Size: 2401 bytes --]

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 #2: Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2011-09-21 13:12 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-13 21:56 [gentoo-dev] new `usex` helper Mike Frysinger
2011-09-13 22:01 ` Alec Warner
2011-09-13 22:13   ` Mike Frysinger
2011-09-13 23:08     ` Brian Harring
2011-09-14  2:45       ` Mike Frysinger
2011-09-14  3:04         ` Brian Harring
2011-09-14  3:43           ` Mike Frysinger
2011-09-14  3:56             ` Brian Harring
2011-09-14  6:02         ` Ulrich Mueller
2011-09-14 14:53           ` Mike Frysinger
2011-09-14  2:02 ` Donnie Berkholz
2011-09-14  2:14   ` Brian Harring
2011-09-14 19:16     ` Donnie Berkholz
2011-09-15  0:29       ` Brian Harring
2011-09-16  3:00         ` Donnie Berkholz
2011-09-16  9:06           ` Brian Harring
2011-09-16 12:30             ` Donnie Berkholz
2011-09-16 14:04               ` Michał Górny
2011-09-16 17:27                 ` Alec Warner
2011-09-16 20:43               ` Brian Harring
2011-09-18  3:59                 ` Donnie Berkholz
2011-09-18 11:22                   ` Brian Harring
2011-09-19  3:16                     ` Donnie Berkholz
2011-09-20 21:20                       ` Brian Harring
2011-09-21 13:11                         ` Donnie Berkholz [this message]
2011-09-21 16:37                           ` Alec Warner
2011-09-23  0:41                             ` Donnie Berkholz
2011-09-23  1:04                               ` Alec Warner
2011-09-23  1:15                                 ` Donnie Berkholz
2011-09-17 21:37             ` Zac Medico
2011-09-14  2:47   ` Mike Frysinger
2011-09-14  5:34   ` Ciaran McCreesh
2011-09-14 19:23     ` Donnie Berkholz
2011-09-14 15:03 ` Mike Frysinger
2011-09-21 19:25 ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110921131156.GA3640@comet \
    --to=dberkholz@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox