From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LcU2t-0003mw-KJ for garchives@archives.gentoo.org; Thu, 26 Feb 2009 00:24:11 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7F932E031E; Thu, 26 Feb 2009 00:24:10 +0000 (UTC) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by pigeon.gentoo.org (Postfix) with ESMTP id 3375AE031E for ; Thu, 26 Feb 2009 00:24:10 +0000 (UTC) Received: by wf-out-1314.google.com with SMTP id 29so285661wff.10 for ; Wed, 25 Feb 2009 16:24:09 -0800 (PST) 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=hunCg5/7t2D6M1t98aKNqReVAhO8pp3Xi3ojKXNPSDY=; b=GT2MmYXB7kkj8gSfimabeBan8+GqFNR4pTt8GihvI1/FLCnOLIeW1iG+h32g2ILVFk MnQh8f4vnS8EZEGBnWmnnvoIzwwovZJxSZYX+ek8OtqQMWnMLBXXl135WuFyhpDeEmsW o+4cWfTB4i/a/82ys3zMD7iWWYS0IpSfrmu6s= 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=SRKU8iNTN9q2eggghiIaw6emcoV+VubpEUGcl+qoBPu6N6vkocr2antYcJmLKrlmwv GYe/6Nb7dMY4N6xkcL3rtAKyZP8tV/3smQaC0HS6iaZ/V1dJBuC6zhr9ojHLh5SL2roS e6dR1qa5VPOWNqKCxeDETzEvyOZg+/fVR90Mw= Received: by 10.142.254.6 with SMTP id b6mr326601wfi.157.1235607849600; Wed, 25 Feb 2009 16:24:09 -0800 (PST) Received: from smtp.gmail.com (c-98-210-196-21.hsd1.ca.comcast.net [98.210.196.21]) by mx.google.com with ESMTPS id 28sm10992445wfd.5.2009.02.25.16.24.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 16:24:09 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Wed, 25 Feb 2009 16:24:45 -0800 Date: Wed, 25 Feb 2009 16:24:45 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives) Message-ID: <20090226002445.GL3506@hrair> References: <49A472E3.1010204@gentoo.org> <20090225124951.GD3506@hrair> <20090225230307.33c9f4f8@snowcone> <20090226000246.GK3506@hrair> <20090226001104.3cec09e5@snowmobile> 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="vSsTm1kUtxIHoa7M" Content-Disposition: inline In-Reply-To: <20090226001104.3cec09e5@snowmobile> User-Agent: Mutt/1.5.16 (2007-06-09) X-Archives-Salt: aa39bd72-b446-442f-b93b-8f886704f869 X-Archives-Hash: a3537f4b78ddf385a4cddb47bf71e880 --vSsTm1kUtxIHoa7M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 26, 2009 at 12:11:04AM +0000, Ciaran McCreesh wrote: > On Wed, 25 Feb 2009 16:02:46 -0800 > Brian Harring wrote: > > Bullshit. First invocation of the ebuild, that means it can do=20 > > whatever it wants to the environment- literally swapping in the EAPI=20 > > environment right then/there. Auto inherits, changing the inherit=20 > > mechanism, everything (this includes shopt adjustments). > >=20 > > Not even sure why you're arguing that one, but back it up w/ examples= =20 > > if you want to continue that line of FUD. >=20 > You can do that on a variable assignment too, with all the same > implications as having it as a function, and a slightly less horrible > upgrade path. You're contradicting your own statements. Pkg level eclasses (if=20 reusing inherit) would explode 'in a user visible manner' if using var=20 only. While the above wasn't FUD, definitely was misinfo. Be consistant=20 please. > > > Global scope die is very very messy. This leaks out to users in the > > > form of horrible messages that make the user think something's badly > > > broken. > >=20 > > One would think "upgrade your manager" would be... self explanatory. = =20 > > Regardless, spelling it out- the user visible barf is only visible on= =20 > > existant managers. > >=20 > > For any manager supporting eapi>2 (thus having the function), the=20 > > function can exist out cleanly (no stderr complaints) from sourcing > > at that point without issue. >=20 > Which is a "wait a year or more" thing... If you do it with a variable > instead of a function, you can at least roll out EAPI 3 (without any > global scope changes, but with the stricter "stop on setting an > unsupported EAPI" requirement) without the wait. There is no reason to wait a year let alone wait for EAPI3 to be=20 defined. The eapi function could be added now in preparation (thus=20 killing the user visible pukage), regardless of eapi 3's timeline. The die exists strictly to be thorough about stragglers. > > Every proposal has uglyness- g55 for example doesn't give the user > > any indication that they're not seeing ebuilds due to EAPI (in other > > words loss of functionality that exists now). >=20 > Given you're a proponent of not showing users things that're merely > masked... Say what you want; g55 still has the flaw. ~harring --vSsTm1kUtxIHoa7M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkml4U0ACgkQsiLx3HvNzgeppgCfXRPachfIOU4OTq9O/eGXvDtG yyYAoIzKPVUBmTkRX4DX4SXlivBao3rB =NDJU -----END PGP SIGNATURE----- --vSsTm1kUtxIHoa7M--