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 1Ogr9G-0008HI-2K for garchives@archives.gentoo.org; Thu, 05 Aug 2010 03:29:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 11B76E094F; Thu, 5 Aug 2010 03:29:32 +0000 (UTC) Received: from mail-gy0-f181.google.com (mail-gy0-f181.google.com [209.85.160.181]) by pigeon.gentoo.org (Postfix) with ESMTP id CD245E08EE for ; Thu, 5 Aug 2010 03:29:06 +0000 (UTC) Received: by gyf1 with SMTP id 1so3610633gyf.40 for ; Wed, 04 Aug 2010 20:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=XfsaPg8LqvlRhYgHqse817IrwgQilvFWJ2LbdDIZMgc=; b=pnopkYy0ciCWj4T7H98wYjjj8NdLjuyRJ/QHYo72oO6hENkY1imC8yNjf3rpbgQsjk 2l2pQSSpczCoT9eZIQtdMTKISjBLYrOWlq8dILov0Y60VcfrNb+3vJKkhoVZwjO0Nh0f pNZmO0Lh2Xjw+qm9UWBuH4jeQuRxjbLM1o8CY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=PszjxOEFwIxmoCfKnozNwJwwoi3ayb0NevgRZN7BwDx7oZ0ByG+xejRreKWcZvbENj F8WqXme0CLNx6R/79ccHIG9yTRV0bhlBjzuUeF2IF7YJEuisr/mQVF+ZdKKyaMlmQVFj U8O0lDw1nJ70EWdKXxxEB7BREmRtAZLTSLiLw= Received: by 10.231.170.13 with SMTP id b13mr11261629ibz.62.1280978946184; Wed, 04 Aug 2010 20:29:06 -0700 (PDT) Received: from smtp.gmail.com (c-67-171-128-62.hsd1.wa.comcast.net [67.171.128.62]) by mx.google.com with ESMTPS id e8sm8646430ibb.2.2010.08.04.20.29.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 20:29:05 -0700 (PDT) Received: by smtp.gmail.com (sSMTP sendmail emulation); Wed, 04 Aug 2010 20:27:02 -0700 Date: Wed, 4 Aug 2010 20:27:02 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: Reviving GLEP33 Message-ID: <20100805032702.GG12708@hrair.al.intel.com> References: <4C569638.9000407@gentoo.org> <20100802211517.1f207d31@snowcone> <4C573EBB.3080005@gentoo.org> 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="Fnm8lRGFTVS/3GuM" Content-Disposition: inline In-Reply-To: <4C573EBB.3080005@gentoo.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: f69cea59-8528-4b86-8831-98d2221f2c63 X-Archives-Hash: cf0420894ed9a824d5d39d1925dbb182 --Fnm8lRGFTVS/3GuM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 02, 2010 at 11:55:07PM +0200, Matti Bickel wrote: > On 08/02/2010 10:15 PM, Ciaran McCreesh wrote: > > Aren't you really after per-package eclasses, not elibs? >=20 > Yes. I don't care whether the snippets may affect metadata. They already > don't (at one time they did, but we got warned that that's illegal - > that's why php-5.3 ebuilds have their metadata folded back into them). >=20 > >> Instead of all the backwards-compatibility issues the GLEP deals with, > >> we could just sneak the implementation into EAPI4 and be done with it. > >=20 > > No, you can't make global scope changes just in an EAPI without > > screwing up user systems. You have to do the whole "wait several years" > > thing for them. While it's been repeated many, many time, this statement is provably=20 false. What _is_ true is that you cannot have new global scope=20 functionality that influences/sets EAPI. That is _accurate_ truth of=20 the matter. If a PM encounters an EAPI it doesn't understand/support, by=20 definition the metadata it tried generating is not usable- the PM=20 doesn't support that new EAPI thus it has zero clue how to=20 generate/store metadata appropriately for that EAPI. Note that since policy forbids EAPI being set in eclasses _anyways_,=20 there isn't a conflict here despite ciaran's claims. If an EAPI adds a new global function that cannot set/influence EAPI,=20 PM's that don't support that EAPI will spit complaints about 'missing=20 command' during sourcing- however the PM will still see the EAPI value=20 is one it knows it doesn't support, and act accordingly. Basically, the only real issue here is that PMs invalidly output=20 stdout/stderr for EAPIs they don't support- this gives the perception=20 that there is an issue, when in reality it's just the PM being=20 slightly user unfriendly. > Bad. So I guess it's back to ferring's "use a new directory not readable > by old PMs" idea. GLEP55++, but having to wait several months for that > and GLEP33 *on top* is not very motivation for me. The reason for a new directory was to enforce a new structuring that=20 was more friendly to changelogs and manifests- due to ECLASSDIR being=20 documented in PMS (and annoyingly eclass-manpagers being the sole=20 consumer of it) adding a new eclasses directory should require a EAPI=20 bump. As for per package eclasses, I'd personally require accessing the=20 package eclass being done via a new inherit function- this avoids some=20 annoying gotchas. That said, I don't see a reason right now that it=20 couldn't be added into an EAPI, per the reasons I laid out earlier in=20 this email. ~brian --Fnm8lRGFTVS/3GuM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkxaL4YACgkQsiLx3HvNzgctoQCg300BtJVWFkMHBFWJRYqopzMi Jn0AoMq9LPEM8hwzA6cvV/9g7hfVp7Ko =2gUX -----END PGP SIGNATURE----- --Fnm8lRGFTVS/3GuM--