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 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 ; 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 ; Fri, 16 Sep 2011 12:30:17 +0000 (UTC) Date: Fri, 16 Sep 2011 07:30:14 -0500 From: Donnie Berkholz 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: 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="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--