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-47672-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1R4XZp-0004AG-LB
	for garchives@archives.gentoo.org; Fri, 16 Sep 2011 12:31:29 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id C1F5021C1F2;
	Fri, 16 Sep 2011 12:31:13 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
	by pigeon.gentoo.org (Postfix) with ESMTP id 2EBCC21C198
	for <gentoo-dev@lists.gentoo.org>; Fri, 16 Sep 2011 12:30:18 +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 6A5D51B4007
	for <gentoo-dev@lists.gentoo.org>; Fri, 16 Sep 2011 12:30:17 +0000 (UTC)
Date: Fri, 16 Sep 2011 07:30:14 -0500
From: Donnie Berkholz <dberkholz@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] new `usex` helper
Message-ID: <20110916123014.GC5000@comet>
References: <201109131756.19714.vapier@gentoo.org>
 <20110914020228.GP31178@comet>
 <20110914021449.GA5106@localhost.hobnob.com>
 <20110914191641.GQ31178@comet>
 <20110915002949.GA16239@localhost>
 <20110916030019.GA5000@comet>
 <20110916090605.GD16239@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="JgQwtEuHJzHdouWu"
Content-Disposition: inline
In-Reply-To: <20110916090605.GD16239@localhost>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Archives-Salt: 
X-Archives-Hash: 211994238aa96f4abef4263b7b96febd


--JgQwtEuHJzHdouWu
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 02:06 Fri 16 Sep     , Brian Harring wrote:
> Specious argument; the point of controllable stacking was to avoid the=20
> issue of overlay's forcing their eclasses upon gentoo-x86 ebuilds=20
> (which may not support those modified eclasses) via the old=20
> PORTDIR_OVERLAY behaviour.  This is why multiple repositories have=20
> layout.conf master definitions- to explicitly mark that they=20
> require/consume a seperate repo.

So let me get this straight =E2=80=94 instead, you want overlay users to=20
maintain a copy of every eclass they use, which will almost=20
automatically become outdated and stale because it won't track the=20
gentoo-x86 version?

> What you're basically proposing is a variation of the "push format=20
> definitions into a central tree, and require everyone to use that=20
> central tree".  This discussion has come and gone; I say that being=20
> one of the folks who was *pushing for the repository solution*.  The=20
> problem there is it fundamentally enables (more forces) fragmentation.

I think Gentoo will always provide one or a set of "official" central=20
repositories, that's pretty much the definition of a distribution. So=20
yes, I'm saying that generally useful stuff could go into one of these=20
repositories, which (in the multi-repo case) could be like the eclass=20
metaphor for repos; others would depend on it implicitly or explicitly.

> Realistically I assume you're taking the stance "EAPI gets in the way,=20
> lets do away with it"- if so, well, out with it, and I'll dredge up=20
> the old logs/complaints that lead to EAPI.

I see EAPI as a nice thing for standardizing features that are=20
implemented in the PM so they work identically across portage, pkgcore,=20
and paludis. But I don't think that implementing things in the PM when=20
they could go in an eclass is automatically the best choice. It=20
dramatically slows down the speed of iteration, prototyping, and bug=20
fixing.

> rephrase please; either you're saying "everyone uses gentoo-x86" which=20
> is sort of true (funtoo/chrome aren't necessarily riding HEAD/trunk=20
> however which means things can get ugly for derivative repository=20
> usage), but still ignores the situations where people have overlays w/=20
> developmental eclasses that they need to selectively control where it=20
> overrides (which is where the notion of repo stacking comes into=20
> play).

I think I explained above, but let me know if that's not the case.

--=20
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com

--JgQwtEuHJzHdouWu
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEABECAAYFAk5zQVYACgkQXVaO67S1rtsT5QCgo7Z3jgb1lX4bOcIqBiC6ZP4c
3d0Amwf3LXBu+7Eq7r7pdvpwpoS2m4SA
=19QX
-----END PGP SIGNATURE-----

--JgQwtEuHJzHdouWu--