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 <gentoo-dev+bounces-36030-garchives=archives.gentoo.org@lists.gentoo.org>)
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 <gentoo-dev@lists.gentoo.org>; Mon, 18 May 2009 15:58:03 +0000 (UTC)
Received: by yx-out-1718.google.com with SMTP id 36so10393054yxh.46
for <gentoo-dev@lists.gentoo.org>; 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: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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: <d77765540905170856wa882914ica3dc4698c03bc96@mail.gmail.com>
<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 <levertond@googlemail.com>
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 <slong@rathaus.eclipse.co.uk>:
> David Leverton wrote:
>
>> 2009/5/17 Ben de Groot <yngwin@gentoo.org>:
>>> 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.