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 1Mbeyk-0001Op-1L for garchives@archives.gentoo.org; Thu, 13 Aug 2009 18:24:46 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0AE2DE05C0; Thu, 13 Aug 2009 18:24:45 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id C2A41E05C0 for ; Thu, 13 Aug 2009 18:24:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 6B95164E9F for ; Thu, 13 Aug 2009 18:24:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 required=5.5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0zePFfGlP3W for ; Thu, 13 Aug 2009 18:24:38 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id C6A5864DFB for ; Thu, 13 Aug 2009 18:24:36 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MbeyS-0000zC-P4 for gentoo-dev@gentoo.org; Thu, 13 Aug 2009 18:24:28 +0000 Received: from 91.85.165.234 ([91.85.165.234]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Aug 2009 18:24:28 +0000 Received: from slong by 91.85.165.234 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Aug 2009 18:24:28 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long Subject: [gentoo-dev] Re: Re: RFC: Make 10.0 profiles EAPI-2 'compliant' Date: Thu, 13 Aug 2009 19:22:16 +0100 Organization: Friendly-Coders Message-ID: <44655500.sygxnxrhqW@news.friendly-coders.info> References: <90b936c0908121058y5fd25cfcm67a19761b1130896@mail.gmail.com> <200908122041.34205.scarabeus@gentoo.org> <20090812194656.47300704@snowcone> <20090813135658.2d497f7b@snowcone> 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: text/plain; charset=utf-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 91.85.165.234 Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 9b84689b-1e0f-46da-bb12-01536fc4d848 X-Archives-Hash: ef1f012f4cbf6d14c2d9ac2d1793f61c Ciaran McCreesh wrote: > On Thu, 13 Aug 2009 12:50:26 +0000 (UTC) > Mark Bateman wrote: >> > On Wed, 12 Aug 2009 20:41:30 +0200 >> > Tom=C3=A1=C5=A1 Chv=C3=A1tal gentoo.org> wrote: >> > > Also we should allow the stuff as directory thingus (portage >> > > already handles it right). >> >=20 >> > That's a seperate thing that needs EAPI control. You'll need to >> > propose it for EAPI 4 if you want that. >>=20 >> Except this "stuff as directory" was pre-EAPI and thus the PMS should >> have captured that as EAPI-1 >> Ergo PMS is wrong and needs to be updated to refect reality >=20 > PMS accurately reflects the Portage documentation and the commit > message that introduced the feature -- it's purely for use > in /etc/portage/, which is beyond the scope of PMS. > If it's pre-EAPI it's part of EAPI '0'. That you neglected to document it= , for whatever reason, is irrelevant. =20 > It is not the business of PMS to enforce undocumented features It's not undocumented, as you just pointed out above. > that Portage supports only by accident Oh, so now you know the minds of the portage developers? I'd like to present an alternative viewpoint: portage developers are happ= y to work to PMS, since it has utility for users. But ultimately, they're n= ot that bothered about pushing for new things, since the process means deali= ng with you; adding features for portage only and leaving it up to the wider community to push for them in EAPIs is an awful lot less hassle. > and that aren't used in the tree.=20 > Circular argument, don't you think? It's not in-tree so we won't put it i= n PMS. It's not in PMS, so it's not allowed in-tree. And don't forget, we have to "claim PMS compliance" to which you are the gatekeeper. =20 I'd like to ask the Council to consider whether EAPI development has not = in fact supplanted a large part of the GLEP process (specifically the technical aspects to do with ebuild development.) As such, insisting on a= ll discussion on bugzilla is in fact a subversion of the original process th= at people have agreed upon. --=20 #friendly-coders -- We're friendly but we're not /that/ friendly ;-)