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 1LcThb-0000Nt-Ue for garchives@archives.gentoo.org; Thu, 26 Feb 2009 00:02:12 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4DB1DE033C; Thu, 26 Feb 2009 00:02:10 +0000 (UTC) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by pigeon.gentoo.org (Postfix) with ESMTP id 11F43E033C for ; Thu, 26 Feb 2009 00:02:10 +0000 (UTC) Received: by wf-out-1314.google.com with SMTP id 29so276976wff.10 for ; Wed, 25 Feb 2009 16:02: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=U/9xiDhXox6xPNp2KrR0OVewgp/TeJTI5y7Inx5oeTk=; b=T1mRvNLVlDE1RIUhJRZJKo7hB8zajTYyAyzM1VrXY19MWXvdmPgf59yBpnUut8uuFE 3ye85VkKTGfyOUrZ7NJpOSWHHyFCDXmxfoW5jQ6Z6JHLe3QzeV5m0vyEfNN8FFUqMxPr mo1V36n0NmIn8rZG4muR70iTm2uqqgCNDtQ20= 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=eyJrTDcRkQ5Mm+h1VoYmmZ3SNV4Nch+dnsp7Fukef28+Zn/894cxznQUx69uFuVcKW AuZNpukE2sbIu3ITBhwKO3jdaBhupKPjlMu/gNTkk9j2RxqkPrUD6O/qlk5CdBQ0GvXu WJdiT5YjvPxb9CJO9uwt31s0hc8uXSl6JWjDQ= Received: by 10.142.173.8 with SMTP id v8mr313894wfe.181.1235606529673; Wed, 25 Feb 2009 16:02: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 9sm14799731wfc.59.2009.02.25.16.02.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 16:02:09 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Wed, 25 Feb 2009 16:02:46 -0800 Date: Wed, 25 Feb 2009 16:02:46 -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: <20090226000246.GK3506@hrair> References: <49A472E3.1010204@gentoo.org> <20090225124951.GD3506@hrair> <20090225230307.33c9f4f8@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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pql/uPZNXIm1JCle" Content-Disposition: inline In-Reply-To: <20090225230307.33c9f4f8@snowcone> User-Agent: Mutt/1.5.16 (2007-06-09) X-Archives-Salt: cac9a72c-05d7-4194-82bf-ce7110f79695 X-Archives-Hash: 15a8d1cb106d6a0df257f5897383c80e --Pql/uPZNXIm1JCle Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 25, 2009 at 11:03:07PM +0000, Ciaran McCreesh wrote: > On Wed, 25 Feb 2009 04:49:51 -0800 > Brian Harring wrote: > > 4) eapi as a function; instead of "EAPI=3D1", do "eapi 1", required as= =20 > > the first statement (simplest way). >=20 > Doesn't solve anything over having it as a variable, and has a messy > upgrade path. >=20 > > - global scope changes can occur (inherit mechanism changes=20 > > included). >=20 > Global scope changes can no more occur than they can with it as a > variable. All it does is changes where the barfing occurs to slightly > earlier on. 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). 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. > > - transition is slightly icky; basically one of the following is=20 > > required- > > a) for EAPI>=3D2, do 'eapi 3 || die "upgrade your manager"'. Reason= =20 > > for this is that current managers obviously lack an eapi > > function, to make managers available *now* blow up the || die is > > required. This solution can be deployed now, no transition required > > although at some point stating "eapi is required retroactively for > > all eapis" would be wise to eliminate the need for the || die (cut=20 > > support basically for old managers) >=20 > 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. 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. For any manager supporting eapi>2 (thus having the function), the=20 function can exist out cleanly (no stderr complaints) from sourcing at=20 that point without issue. > > b) bashrc trickery, defines an eapi if it's unset. Said eapi=20 > > function exports EAPI=3D$1, optionally triggering a die if the eapi= =20 > > isn't 0,1,2 (since any later eapi would require a manager upgrade= =20 > > which would also have the eapi function). >=20 > Unportable, and still leaks out to users. Two options were given there; one 'leaks out to users', the other is=20 the old behaviour (eapi env setting)- again, this is only visible for=20 the window of pre eapi 3 managers, meaning it's a one time hit (rather=20 then continual as you're implying). Every proposal has uglyness- g55 for example doesn't give the user any=20 indication that they're not seeing ebuilds due to EAPI (in other words=20 loss of functionality that exists now). ~brian --Pql/uPZNXIm1JCle Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkml3CYACgkQsiLx3HvNzgeW3gCgvtn3itDpQ3ZhYZx409SlLXiW yxsAoNXONfBwqapbdPYBsSqXhjQsl7xC =4QKL -----END PGP SIGNATURE----- --Pql/uPZNXIm1JCle--