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 1KKZb2-0002uW-1M for garchives@archives.gentoo.org; Sun, 20 Jul 2008 14:09:08 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 58BD8E0377; Sun, 20 Jul 2008 14:09:06 +0000 (UTC) Received: from nexon.nexon.ath.cx (84-217-48-14.tn.glocalnet.net [84.217.48.14]) by pigeon.gentoo.org (Postfix) with ESMTP id EAE2EE0377 for ; Sun, 20 Jul 2008 14:09:05 +0000 (UTC) Received: by nexon.nexon.ath.cx (Postfix, from userid 1000) id BBC276B99CF; Sun, 20 Jul 2008 16:08:57 +0200 (CEST) Date: Sun, 20 Jul 2008 16:08:57 +0200 From: Patrick =?utf-8?Q?B=C3=B6rjesson?= To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Council meeting summary for 10 July 2008 Message-ID: <20080720140857.GG603@nexon.nexus> References: <20080713071118.GC1891@comet> <20080713235255.0e2b7f8e@googlemail.com> <1216561122.4891.97.camel@camobap> 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="V32M1hWVjliPHW+c" Content-Disposition: inline In-Reply-To: <1216561122.4891.97.camel@camobap> User-Agent: Mutt/1.5.16 (2007-06-09) X-Archives-Salt: cbdc7350-fb8d-4a4b-a3a2-36df2259c137 X-Archives-Hash: 9ae07e72dc49c9d454c0897e57494030 --V32M1hWVjliPHW+c Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-07-20 17:38, Peter Volkov uttered these thoughts: > =D0=92 =D0=92=D1=81=D0=BA, 13/07/2008 =D0=B2 23:52 +0100, Ciaran McCreesh= =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > Which part of the 'Problem' section in the GLEP didn't you understand? > > Do you seriously consider not being able to add or change global scope > > functions in future EAPIs to be a non-issue, or were you ignoring those > > two bullet points? >=20 > I've read all previous discussions but still miss answer to the > question: Why is it impossible to state that .ebuild extension is for > bash based ebuild make package manager get and filter EAPIs based on > EAPI variable? Because that would still not allow global scope changes, because in order= =20 to get to know which EAPI the ebuild is written in, you have to actually source the ebuild, and by then it's too late. Unless you introduce some inane requirement that the EAPI variable has to be the first thing stated in the ebuild and force the PMs to extract that value before actually starting to parse the ebuild. Now, if _that's_ not an ugly solution, i don't know what is... You have to know _how_ to interpret an ebuild _before_ you actually start doing it. > Note, I assume that we can do not backward-compatible changes in PM, we > just need to wait enough time to start using it. But taking into account > that the features that will make use of this GLEP55 are still not so > evident I don't see any problem to wait. In any case I'd like to > understand why should we start support this hell of extensions. Reasons for the change has been stated before, and the one i just explained is the main one so far as i know.=20 --=20 () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. --V32M1hWVjliPHW+c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiDRvkACgkQ4O+nwAQPsUk8lgCggMruX14t2u13ShvKGleuTKo2 NeoAn26T7FIYWhDIXUkbbfYSK4LTlM60 =+BDa -----END PGP SIGNATURE----- --V32M1hWVjliPHW+c--