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 1R58Xq-0007ox-RN for garchives@archives.gentoo.org; Sun, 18 Sep 2011 03:59:55 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 422D421C1D5; Sun, 18 Sep 2011 03:59:46 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D421E21C1C7 for ; Sun, 18 Sep 2011 03:59:10 +0000 (UTC) Received: from localhost (24-179-244-217.dhcp.roch.mn.charter.com [24.179.244.217]) (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 47C9B1B4009 for ; Sun, 18 Sep 2011 03:59:10 +0000 (UTC) Date: Sat, 17 Sep 2011 22:59:08 -0500 From: Donnie Berkholz To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] new `usex` helper Message-ID: <20110918035908.GB4525@comet.mayo.edu> 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> <20110916123014.GC5000@comet> <20110916204315.GA30103@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="dc+cDN39EJAMEtIO" Content-Disposition: inline In-Reply-To: <20110916204315.GA30103@beast> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: X-Archives-Hash: 616923872bcc5f85fecf66fd6dc6d44d --dc+cDN39EJAMEtIO Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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/; I'm not necessarily requiring that every repository must automatically=20 use gentoo-x86 =E2=80=94 just the ones that want to use features in an ecla= ss=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. What I'm suggesting is that we should add useful stuff to eclasses by=20 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 to=20 come into it at all. > aside from meaning that the format definition can now *vary*, which is=20 > great for wasting dev time and screwing up compatibility, it opens up=20 > tweaking/customizing that functionality- aka,=20 > fragmentation/divergence. People doing that outside gentoo-x86 should do it the same way as ones=20 within it, by bumping the eclass to a new unique name. Ideally one=20 that's not just a numeric value so it won't conflict with ours, in the=20 same way as EAPI naming. > If we did the sort of thing you're basically pushing for, how long do=20 > you think it would be till funtoo added support for a new archive=20 > format to unpack? That's a *simple*, and *likely* example of how this=20 > can diverge. So, what I'm getting out of this is that we should make it harder for=20 derivative distributions to innovate? Why should I care if they want to=20 do stuff with new archive formats? > Further, doing as you propose means we're flat out, shit out of luck=20 > /ever/ distributing a usable cache for standalone repositories. If=20 > they're bound to the changes of another repository, distributing a=20 > cache in parallel is pointless (and not doable in current form since=20 > metadata/cache lacks necessary eclass validation data for overlay=20 > inheritance). Not much different from other cross-repository dependencies; you have to=20 keep everything in lockstep because who knows what other people will do=20 with their repos. Maybe people would want to distribute their own copies=20 of forked dependent repositories too, I haven't thought much about it. --=20 Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com --dc+cDN39EJAMEtIO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEABECAAYFAk51bIwACgkQXVaO67S1rtteSgCeIhf1sHHddWM2oe+8Fu4Tag5v r10AoIDT9p3Z6ACPkAW5xfsX6ZyoEjor =BLGV -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO--