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 1MdDZq-0001QN-EF for garchives@archives.gentoo.org; Tue, 18 Aug 2009 01:33:30 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4DAE6E0471; Tue, 18 Aug 2009 01:33:29 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 0C0ECE0471 for ; Tue, 18 Aug 2009 01:33:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id B185665A52 for ; Tue, 18 Aug 2009 01:33:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 required=5.5 tests=[AWL=0.148, BAYES_00=-2.599, 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 zZRk2i1uS-98 for ; Tue, 18 Aug 2009 01:33:22 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 0CB9764BB0 for ; Tue, 18 Aug 2009 01:33:20 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1MdDZd-0002Ut-QA for gentoo-dev@gentoo.org; Tue, 18 Aug 2009 03:33:17 +0200 Received: from 82.152.172.133 ([82.152.172.133]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Aug 2009 03:33:17 +0200 Received: from slong by 82.152.172.133 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 18 Aug 2009 03:33:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long Subject: [gentoo-dev] Re: Re: Re: RFC: Make 10.0 profiles EAPI-2 'compliant' Date: Tue, 18 Aug 2009 02:30:55 +0100 Organization: Friendly-Coders Message-ID: <3865504.XFPclIEk6a@news.friendly-coders.info> References: <90b936c0908121058y5fd25cfcm67a19761b1130896@mail.gmail.com> <200908122041.34205.scarabeus@gentoo.org> <20090812194656.47300704@snowcone> <20090813135658.2d497f7b@snowcone> <44655500.sygxnxrhqW@news.friendly-coders.info> <20090813193451.31961a95@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=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 82.152.172.133 Sender: news X-Archives-Salt: 6863b555-7c19-4180-9478-62ee52b6e8f5 X-Archives-Hash: f363ddc160b2d96c1e9a5226631e89f0 Ciaran McCreesh wrote: > On Thu, 13 Aug 2009 19:22:16 +0100 > Steven J Long wrote: >> > 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. > > No, it's not part of EAPI 0. If it's a feature that is pre-PMS, it's part of EAPI-0. The definition is flexible, presumably to avoid this kind of runaround. > It's an accident. If you'd like another > example of an accident, Portage won't complain if you stick garbage in > certain metadata keys; this does not mean PMS should say that it's > legal to put garbage in metadata keys. > That's irrelevant and you know it, apart from being one of your usual political digs at portage. >> > It is not the business of PMS to enforce undocumented features >> It's not undocumented, as you just pointed out above. > > Using it in the tree is undocumented. But it's not an "undocumented feature" is it? > Using it in user configuration is beyond the scope of PMS. Define 'user' >> > that Portage supports only by accident >> Oh, so now you know the minds of the portage developers? > > Yes. No, you clearly do not, as this shows: > I know that they said when adding the directory feature that it > was for use in user configuration files. That's what the commit message > said, and that's what the documentation patch said. The documentation > change explicitly only allowed the feature in user configuration, not > the tree. > > Had the feature intended to be tree-usable, the documentation change > would have said so. > Thanks for explaining what "the Portage documentation and the commit message" means. And yeah, you can read it. Well done. It *does not* mean you know what future directions might have been envisaged. >> > and that aren't used in the tree. >> >> Circular argument, don't you think? It's not in-tree so we won't put >> it in PMS. It's not in PMS, so it's not allowed in-tree. > > That's only a circular argument if you snip out the rest of the > sentence. > Nonsense. You gave the fact that it's not used in the tree as a reason not to put it in PMS, did you not? I merely addressed it separately, since it is a distinct semantic component. >> 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 all discussion on bugzilla is in fact a subversion of >> the original process that people have agreed upon. > > Moving the discussion to bugzilla was the Council's decision, not mine. > Yes, well, I didn't ask you. I asked the Council to consider the broader picture, which is their role, since effectively GLEPs are now only for non-technical things, or might as well be, since all future ebuild directions are EAPI by definition. Having wider input (which is what this list is for) might avoid future blind-alleys. Nevertheless, I'm sure they'll take your valuable insight under consideration, as well as the history and any lobbying that might have gone on at the time, assuming they were around and haven't suppressed the memory. -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)