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 <gentoo-dev+bounces-47741-garchives=archives.gentoo.org@lists.gentoo.org>)
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 <gentoo-dev@lists.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>; Mon, 19 Sep 2011 03:16:49 +0000 (UTC)
Date: Sun, 18 Sep 2011 22:16:46 -0500
From: Donnie Berkholz <dberkholz@gentoo.org>
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: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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--