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 1R5UMP-0005DN-Lf for garchives@archives.gentoo.org; Mon, 19 Sep 2011 03:17:33 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BC9F721C0B0; Mon, 19 Sep 2011 03:17:23 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 1036221C06C for ; Mon, 19 Sep 2011 03:16:49 +0000 (UTC) Received: from localhost (174-25-234-172.rstr.qwest.net [174.25.234.172]) (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 4AD7E1B4028 for ; Mon, 19 Sep 2011 03:16:49 +0000 (UTC) Date: Sun, 18 Sep 2011 22:16:46 -0500 From: Donnie Berkholz To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] new `usex` helper Message-ID: <20110919031646.GA7635@comet> References: <20110914020228.GP31178@comet> <20110914021449.GA5106@localhost.hobnob.com> <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> 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="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <20110918112238.GB6005@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: X-Archives-Hash: e94bd1ee6be0b74b5ee0ae42292a0a3e --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 04:22 Sun 18 Sep , Brian Harring wrote: > On Sat, Sep 17, 2011 at 10:59:08PM -0500, Donnie Berkholz wrote: > > On 13:43 Fri 16 Sep , Brian Harring wrote: > > > What I said from the getgo and you're missing is that pushing EAPI=20 > > > implementation into the tree and ignoring EAPI, or having this notion= =20 > > > that every repository must automatically use gentoo-x86 (pushing the= =20 > > > format into the tree) is /wrong/; > >=20 > > I'm not necessarily requiring that every repository must automatically= =20 > > use gentoo-x86 ??? just the ones that want to use features in an eclass= =20 > > distributed with gentoo-x86. It sounds to me like the logical=20 > > consequence of what you're saying is that every useful function that's= =20 > > now or could eventually be in an eclass must instead be incorporated=20 > > into EAPI. I guess I just don't see where you're drawing the line. >=20 > Drawing it back to what spawned it; usex. This isn't git.eclass, this=20 > isn't svn.eclass, nor is it any of the other complex eclass=20 > functionality. It's a core function that benefits the rest and should=20 > be in EAPI. OK, so the implication of what you're saying is that everything in=20 eutils.eclass, base.eclass, toolchain-funcs.eclass, flag-o-matic.eclass,=20 versionator.eclass, multilib.eclass, prefix.eclass, savedconfig.eclass,=20 and maybe even linux-info.eclass and autotools{,-utils}.eclass should go=20 into EAPI. All that stuff is pretty generally useful features. > > What I'm suggesting is that we should add useful stuff to eclasses=20 > > by default. If people want to use that stuff, they can stack on the=20 > > gentoo-x86 repo and inherit the eclass. I don't know why EAPI needs=20 > > to come into it at all. >=20 > Stacking on gentoo-x86 means you get *everything* for that repository. = =20 > If all you want is a random function out of eutils, that's a *lot* of=20 > uncontrolled change to have intermixed with your overlays eclasses=20 > (even worse, if the eclasses truly overlay into gentoo-x86, that=20 > introduces compatibility issues there too). Yeah, it seems like the ability to do partial stacking would be nice.=20 Perhaps to do so, one wouldn't stack by default but would have a way to=20 specify cross-repo dependencies (including eclasses) or file-specific=20 UUIDs of some sort. > > > aside from meaning that the format definition can now *vary*,=20 > > > which is great for wasting dev time and screwing up compatibility,=20 > > > it opens up tweaking/customizing that functionality- aka,=20 > > > fragmentation/divergence. > >=20 > > People doing that outside gentoo-x86 should do it the same way as=20 > > ones within it, by bumping the eclass to a new unique name. Ideally=20 > > one that's not just a numeric value so it won't conflict with ours,=20 > > in the same way as EAPI naming. >=20 > They should, but api compatibility of an eclass *can* be fluid- in the=20 > past it was a locked API purely because of portage environment saving=20 > issues. That's been resolved, there isn't any strict requirement that=20 > the eclass maintain API compat now. You're trying to rely on people=20 > doing best practices- for format building blocks=20 > (use_with/usex/unpack/etc), that's not sane. Which still pisses me off. It's like a shared library changing its API=20 without bumping SONAME. That makes me wonder whether there's some way we=20 could "enforce" it, at least on the level of repoman or test suites to=20 examine whether the public interface changed, perhaps by generating a=20 cache of the interfaces and comparing to them. > I suspect an easier way to wrap this thread up is if you just state=20 > what you want for backwards compatibility- in a seperate thread you=20 > already proposed basically locking out systems older than 6 months,=20 > and this discussion (moreso the "eapi slows our development" subtext)=20 > is along the same lines. Actually Zac said that, and I was trying to clarify if that's really=20 what he was saying. 9-12 months is more my feeling, as it gets extremely=20 difficult to maintain Gentoo systems without guru-level knowledge around=20 there. (Spoken as someone who still gets support emails from a couple of=20 previous positions.) While I would like there to be a "proper" way to express repo-level=20 dependencies, properly announce deprecation and updates (e.g. to bash 4)=20 in advance as a feature integrated with the PM, and so on, I don't think=20 we should block our ability to move forward on these things. The=20 situation is essentially the same as it's always been, but our old=20 solution is no longer considered good enough and we don't have a new one=20 in place, so we're just sitting here. > Layout what you think it should be, Layout of what, exactly? > how you think EAPI should be managed (what goes in, what doesn't,=20 > etc), If it can go in an eclass without strange contortions, put it there. > how derivatives should be handled, With white gloves. More seriously, people making derivatives should have=20 maximal freedom to experiment, and I'm guessing most of them don't want=20 to deal with modifying 3 different PMs written at least partially in 3=20 different languages. They'd rather instantaneously support things in the=20 same language they use for everything else. > how we'll deal w/ installations/derivative distros that grab=20 > snapshots of the tree and run from that (chromeos is a public example,=20 > I've seen multiple private deployments using the same approach), Being explicit about our level of support is what we need to do, no=20 matter what that level is, so external groups can figure out how to deal=20 with that timeline. Our current council-mandated standard is a year, as=20 Ulm mentioned in another post, but I'm not aware of any of our=20 documentation that actually says this. It would obviously be good to flood our users with communication=20 (website, -announce, news items, etc) before anything that broke even=20 just the oldest installations. --=20 Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEABECAAYFAk52tB4ACgkQXVaO67S1rtt8/ACeLFxokHXbZYEE0xz7NkwCkGt/ DD8AoNp0ufkXKtGh3Ej49A0IC1y+90pR =zUpP -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl--