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 1M65E5-0006Q7-3m for garchives@archives.gentoo.org; Mon, 18 May 2009 15:58:05 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 05C3FE031A; Mon, 18 May 2009 15:58:04 +0000 (UTC) Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.154]) by pigeon.gentoo.org (Postfix) with ESMTP id D3419E031A for ; Mon, 18 May 2009 15:58:03 +0000 (UTC) Received: by yx-out-1718.google.com with SMTP id 36so10393054yxh.46 for ; Mon, 18 May 2009 08:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=aRUfjSTy5qF1QrKt4o/bW2IY0O9V5veZIQP3HGhfylA=; b=biuiC+isTSugFGXVi92CJkFGrS8w7MoConbm0WrapGxnrTfRRA+iSqk46DErvckhQY mBSuNofswDGDGPVk8WWLKPvBpT28flfRVxbReTxjovuV6o8PKjY4FjJBGpnxdvbDcUnq zmSzyMA3T5GE1AW42mCYIpehann9Tf58Kn/6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=plF9piVHGu/O6y+vF8zfyVNk3ugwTUpVFwvT89MS36Wbjr9iQcIr7Hc5x9DKhSuKBc bU2J4bK30fMrzXxr7rmzQ+Dnx0XsCotOrUJvjYFVcgNNp63VxjYuCM9P/CVEIA8W2kCH eFvlBca27lfqJ6oqO1eNanbO3QgoDdWctj8Co= 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 Received: by 10.90.113.17 with SMTP id l17mr6027048agc.65.1242662283510; Mon, 18 May 2009 08:58:03 -0700 (PDT) In-Reply-To: <2646486.dWnxjHJ5df@news.friendly-coders.info> References: <7c612fc60905170920k22189731i2540514e24e60959@mail.gmail.com> <18960.18295.65849.57779@a1ihome1.kph.uni-mainz.de> <4A104BCE.7000001@gentoo.org> <4A107F05.7020001@gentoo.org> <20090517222016.3164b564@snowmobile> <4A108AC5.30309@gentoo.org> <75f3dce80905171515p11cdbcf3v25dbefbe11ba1ec2@mail.gmail.com> <2646486.dWnxjHJ5df@news.friendly-coders.info> Date: Mon, 18 May 2009 16:58:03 +0100 Message-ID: <75f3dce80905180858l53dc6589yccb5c6a441d62322@mail.gmail.com> Subject: Re: [gentoo-dev] Re: GLEP 55 updated From: David Leverton To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: b038a97d-d0b3-47e1-a8ff-dca96cd744b9 X-Archives-Hash: eb547d33923c0addb1302a4c64a545cb 2009/5/18 Steven J Long : > David Leverton wrote: > >> 2009/5/17 Ben de Groot : >>> I think the way eapi-2 was introduced into the tree wasn't particularly >>> problematic. >> >> I think there might be a misunderstanding here. Ciaran means functions >> provided by the package manager that ebuilds can call during metadata >> generation, for example built-in versionator-like functionality, not >> new phase functions like src_prepare and src_configure. > > Ugh. Firstly versionator is a piece of bloated crap that should have died a > long time ago; all it does is stop Gentoo newbs learning the basics[1] of > their implementation language, which leaves them open to nonsensical > arguments about printf -v (glad you finally learnt that one, btw.) Yes, it should have died a long time ago, that's why we're talking about adding equivalent built-in functionality. Please try to keep up. (And it's always amusing to see your bizarre delusions about what I do and don't know.) > Secondly, please explain fully and clearly, but concisely, why we can't > simply state that EAPI=NN allows the ebuild to use the EAPI functions in > global scope. Because by the time the package manager knows the EAPI and is in a position to provide the appropriate functions, the ebuild will have already tried to use them. > Bear in mind that you have to deal with the case of the mangler which can > get EAPI from an ebuild without sourcing, as portage currently can, I > believe. Interesting.... > Relaxing that restriction strikes me as much saner than relaxing all the > other restrictions which make interoperability easier. > > (Frankly, I'm amazed at having to state that to people trusted to write a > specification. Follow up to -project on this point please, as it's about > process, not technique.) You're amazed that people trusted to write a specification don't already know what "strikes you as much saner"? Believe it or not, the world does not revolve around you and your opinions.