From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1R6Pny-00054v-Bz for garchives@archives.gentoo.org; Wed, 21 Sep 2011 16:37:50 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E668A21C1A2; Wed, 21 Sep 2011 16:37:41 +0000 (UTC) Received: from mail-vw0-f52.google.com (mail-vw0-f52.google.com [209.85.212.52]) by pigeon.gentoo.org (Postfix) with ESMTP id 9C0DD21C190 for ; Wed, 21 Sep 2011 16:37:16 +0000 (UTC) Received: by vws10 with SMTP id 10so2784593vws.11 for ; Wed, 21 Sep 2011 09:37:16 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.52.116.69 with SMTP id ju5mr811990vdb.258.1316623035919; Wed, 21 Sep 2011 09:37:15 -0700 (PDT) Sender: antarus@scriptkitty.com Received: by 10.52.158.99 with HTTP; Wed, 21 Sep 2011 09:37:15 -0700 (PDT) In-Reply-To: <20110921131156.GA3640@comet> References: <20110914191641.GQ31178@comet> <20110915002949.GA16239@localhost> <20110916030019.GA5000@comet> <20110916090605.GD16239@localhost> <20110916123014.GC5000@comet> <20110916204315.GA30103@beast> <20110918035908.GB4525@comet.mayo.edu> <20110918112238.GB6005@localhost> <20110919031646.GA7635@comet> <20110920212057.GA14344@beast> <20110921131156.GA3640@comet> Date: Wed, 21 Sep 2011 09:37:15 -0700 X-Google-Sender-Auth: 5c0LONLLnXQS_XFwdEAW2bnIym0 Message-ID: Subject: Re: [gentoo-dev] new `usex` helper From: Alec Warner To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: de2ca1e9a903f07d52fd0ae9f7b76279 On Wed, Sep 21, 2011 at 6:11 AM, Donnie Berkholz wro= te: > On 14:20 Tue 20 Sep =C2=A0 =C2=A0 , 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. =C2=A0Some of that (base.eclass for example) is EA= PI >> 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. =3D) > >> > > 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. =C2=A0That's been resolved, there isn't any strict >> > > requirement that the eclass maintain API compat now. =C2=A0You'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. =C2=A0It's one component th= at >> is distributed alone, but consumed by others. =C2=A0There 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. =C2=A0Overlay stacking just makes it possible for a thi= rd >> 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. I think people do this for three reasons. 1) There are no refactoring tools that I know of for bash. 2) There exist some package maintainers that will yell at you if you touch their packages for any reason. 3) Breaking things means they get fixed. We have this notify -> deprecate -> break workflow; I actually don't mind it (but only because I've seen it used elsewhere.) -A > > -- > Thanks, > Donnie > > Donnie Berkholz > Council Member / Sr. Developer > Gentoo Linux > Blog: http://dberkholz.com >