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 1R6MbW-0002mk-8i for garchives@archives.gentoo.org; Wed, 21 Sep 2011 13:12:46 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A3E4E21C0F8; Wed, 21 Sep 2011 13:12:35 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 038DB21C05D for ; Wed, 21 Sep 2011 13:11:59 +0000 (UTC) Received: from localhost (66-191-141-186.static.roch.mn.charter.com [66.191.141.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dberkholz) by smtp.gentoo.org (Postfix) with ESMTPSA id 2ED551B4005 for ; Wed, 21 Sep 2011 13:11:59 +0000 (UTC) Date: Wed, 21 Sep 2011 08:11:56 -0500 From: Donnie Berkholz To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] new `usex` helper Message-ID: <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> 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <20110920212057.GA14344@beast> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: X-Archives-Hash: b4459976dfb8c3f78058bf0f0c9a9271 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=20 > > eutils.eclass, base.eclass, toolchain-funcs.eclass,=20 > > flag-o-matic.eclass, versionator.eclass, multilib.eclass,=20 > > prefix.eclass, savedconfig.eclass, and maybe even linux-info.eclass=20 > > and autotools{,-utils}.eclass should go into EAPI. All that stuff is=20 > > pretty generally useful features. >=20 > Approximately... yes. Some of that (base.eclass for example) is EAPI=20 > compatibility that can't be folded in (would require retroactively=20 > addding to an EAPI), others aren't yet stabilized (true multilib for=20 > example, seems to still be under discussion), etc. >=20 > 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=20 > > > the past it was a locked API purely because of portage environment=20 > > > saving issues. That's been resolved, there isn't any strict=20 > > > requirement that the eclass maintain API compat now. You're=20 > > > trying to rely on people doing best practices- for format building=20 > > > blocks (use_with/usex/unpack/etc), that's not sane. > >=20 > > Which still pisses me off. It's like a shared library changing its=20 > > API without bumping SONAME. >=20 > I think you're viewing this wrong; if we're talking about openssl=20 > breaking API/ABI w/out bumping soname, sure. It's one component that=20 > is distributed alone, but consumed by others. There is no way to=20 > atomically deploy the new API at the same time as all of the consumers=20 > being updated for it. >=20 > That is /not/ the case of gentoo-x86; eclasses for us are equivalent=20 > to bundled libs. Overlay stacking just makes it possible for a third=20 > party component to reach in and use what is effectively an internal=20 > lib. Not really, because when you update a bundled lib you actually make your=20 whole app compile with it. People change the APIs of eclasses and then=20 just let every internal consumer (ebuilds in gentoo-x86) break. Maybe if=20 we put the burden on the one who changed the API, like the Linux kernel=20 model, it would bother me less. --=20 Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEABECAAYFAk554pwACgkQXVaO67S1rtuQPwCg0Ok4Q8Shcm+PYRpH9RqRBjSy 5JEAoNv5oOIpywG5icI0Y8C4gAcvmykn =3w9n -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF--