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 1OhE1N-00035W-JN for garchives@archives.gentoo.org; Fri, 06 Aug 2010 03:55:01 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 881ECE0815; Fri, 6 Aug 2010 03:54:50 +0000 (UTC) Received: from mail-iw0-f181.google.com (mail-iw0-f181.google.com [209.85.214.181]) by pigeon.gentoo.org (Postfix) with ESMTP id BB06EE079D for ; Fri, 6 Aug 2010 03:54:17 +0000 (UTC) Received: by iwn6 with SMTP id 6so899211iwn.40 for ; Thu, 05 Aug 2010 20:54:17 -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=5AgIZd52QoSrixO+HTDJIMtYc5D5q33/1E4q5tbTBik=; b=nWauNQ8IDcYfRGsVMDqI0XzoMRdOqDqXEqTltwCnPxklaDWfnfW7RFBiVWHiAfIPOv ILFftDjoUi9V6bcoOZ+nRZCSmWeGig6lho9F3pfLNxqL/4fQrgAO+egNUl5Oht9Bd0ss Nc7ThZKmmKjnqV+2hPT1KMswbZYB0JuMJfkM0= 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=CKx8TxB1PZfvc6svlO3MbgJVQOivTW/p3LhnCz3aqfcq6zIaPmzKB4qzLj5vJ2yTZS G671bdhFIUiNEPh0cuq7LYM/q0FI7Pc1t145bE/y3cWoe2q0YUQYgbhVCTa3YmPwMqc4 5fACd6QFPJjZCKkpJhZVwPyRnf938z2dZIdWM= Received: by 10.231.146.196 with SMTP id i4mr12144927ibv.110.1281066857413; Thu, 05 Aug 2010 20:54:17 -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 g31sm761148ibh.4.2010.08.05.20.54.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 20:54:14 -0700 (PDT) Received: by smtp.gmail.com (sSMTP sendmail emulation); Thu, 05 Aug 2010 20:52:12 -0700 Date: Thu, 5 Aug 2010 20:52:12 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: Reviving GLEP33 Message-ID: <20100806035212.GI12708@hrair.al.intel.com> References: <4C569638.9000407@gentoo.org> <20100802211517.1f207d31@snowcone> <4C573EBB.3080005@gentoo.org> <20100805032702.GG12708@hrair.al.intel.com> <4C5AF34C.2010608@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="y96v7rNg6HAoELs5" Content-Disposition: inline In-Reply-To: <4C5AF34C.2010608@gentoo.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 558f34ee-8895-445a-bf54-5f025ebb5a5d X-Archives-Hash: 75baabfe699195ce41fbe6224e4314b7 --y96v7rNg6HAoELs5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 05, 2010 at 07:22:20PM +0200, Matti Bickel wrote: > On 08/05/2010 05:27 AM, Brian Harring wrote: > > 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. >=20 > I guess the point here is that we need a stable version of PMs for a > reasonable time before we switch tree ebuilds to it. > People will hate me if I use EAPI4 functionality in php ebuilds as soon > as councils approves EAPI4. Security might want a word with me if it's a > fast-stable security release. >=20 > But this is orthogonal to GLEP55, afaik. Glep55 suffers the same, rather than being orthogonal. Alternatively phrased, you can't start using a new feature until=20 support is out there. So after an EAPI is defined, you've got a month=20 or so realistically, and that's assuming portage/friends support the=20 EAPI at the time it's minted as official. > >> Bad. So I guess it's back to ferring's "use a new directory not readab= le > >> by old PMs" idea. GLEP55++, but having to wait several months for that > >> and GLEP33 *on top* is not very motivation for me. > >=20 > > 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. >=20 > I'm not going to argue that PMS doesn't seem to say anything about the > content of ECLASSDIR other than that eclasses are stored inside it. > A new dir is fine with me. Can we have that in EAPI4 or is that already > being finalized? EAPI4 is a bit up in the air from where I'm sitting. Write up=20 a proposal (or clean up the g33 glep) and push it- even if you miss=20 eapi4 (doubtful), it'll be in the next eapi. > > 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. >=20 > Okay, so how can I, as somebody not familiar with PM dev process and > roadmaps, help in getting this done? I'd suggest roughly the following- pkg-inherit ['the per pkg-name'] ; specifically, pkg-inherit=20 automatically grabs some commonly named package eclass- or you can=20 optionally override the per package eclass to use. The reason for the option is in transitioning away from an old eclass=20 implementation, or having an eclass per major version (assuming the=20 major versions warrant a seperate eclass). Note that '/' and friends should be banned from the invocation, to=20 prevent a pkg-inherit from trying to reach into another packages=20 eclasses. ~brian --y96v7rNg6HAoELs5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkxbhuwACgkQsiLx3HvNzgf4cwCgtp162W3cNAG+t00wxBCjh6HP zJUAoKRicCQN0sY4yKc4Qa2kYMYmOrng =7rrD -----END PGP SIGNATURE----- --y96v7rNg6HAoELs5--