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 1LcS6F-00020o-1D for garchives@archives.gentoo.org; Wed, 25 Feb 2009 22:19:31 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ECB89E0474; Wed, 25 Feb 2009 22:19:29 +0000 (UTC) Received: from mta21.charter.net (mta21.charter.net [216.33.127.81]) by pigeon.gentoo.org (Postfix) with ESMTP id CD172E0474 for ; Wed, 25 Feb 2009 22:19:29 +0000 (UTC) Received: from imp09 ([10.20.200.9]) by mta21.charter.net (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090225221917.CDHL7559.mta21.charter.net@imp09> for ; Wed, 25 Feb 2009 17:19:17 -0500 Received: from agaffney.org ([71.81.81.248]) by imp09 with charter.net id LNKG1b00M5MTQ6X05NKHoa; Wed, 25 Feb 2009 17:19:17 -0500 Received: from [172.16.2.200] (unknown [140.239.32.26]) by agaffney.org (Postfix) with ESMTPA id 794721E0045 for ; Wed, 25 Feb 2009 16:19:16 -0600 (CST) Message-ID: <49A5C3E3.1090209@gentoo.org> Date: Wed, 25 Feb 2009 16:19:15 -0600 From: Andrew Gaffney User-Agent: Thunderbird 2.0.0.19 (X11/20090102) 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives References: <49A472E3.1010204@gentoo.org> <20090225124951.GD3506@hrair> In-Reply-To: <20090225124951.GD3506@hrair> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 8d785116-98c8-43d7-b2ef-d8268491f041 X-Archives-Hash: 2435a72ef95aa24b96ad156928aee050 Brian Harring wrote: > > 4) eapi as a function; instead of "EAPI=1", do "eapi 1", required as > the first statement (simplest way). > pros: > - global scope changes can occur (inherit mechanism changes > included). > - expanding on the first, auto inherits (pkg level) are possible- > effectively when eapi gets invoked the manager is in control and > can do whatever is desired setting up the env wise. > - bash version requirements can be leveled (bash parses as it goes, > meaning that essentially it won't parse what follows 'eapi 2' till > that command statement finishes) > - fits w/ the existing semantics nicely enough. > cons: > - mangling the version rules for pkgs still isn't possible; no -scm. > Arguable if -scm is even desired, but being explicit about it not > covering this. > - transition is slightly icky; basically one of the following is > required- > a) for EAPI>=2, do 'eapi 3 || die "upgrade your manager"'. Reason > 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 > support basically for old managers) > b) bashrc trickery, defines an eapi if it's unset. Said eapi > function exports EAPI=$1, optionally triggering a die if the eapi > isn't 0,1,2 (since any later eapi would require a manager upgrade > which would also have the eapi function). > > Personally, if g54 is ixnayed #4 I tend to think is the best option > out there- if g54 is forced in, g55 (or at least something that > adjusts the extension to make it invisible to current managers) is > required. > > Commentary? Tend to think #4 is the most aesthetically pleasing to > folk, but who knows... > ~harring I really like this idea, but nobody else seems to have commented on it. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Genkernel + Release Engineering Lead