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 --]
next prev parent 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