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 1LbWXd-0007bJ-O6 for garchives@archives.gentoo.org; Mon, 23 Feb 2009 08:51:57 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BAFF1E03EB; Mon, 23 Feb 2009 08:51:55 +0000 (UTC) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by pigeon.gentoo.org (Postfix) with ESMTP id 7DFB9E03EB for ; Mon, 23 Feb 2009 08:51:55 +0000 (UTC) Received: by wf-out-1314.google.com with SMTP id 29so2100954wff.10 for ; Mon, 23 Feb 2009 00:51:55 -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=xSoNKD5WfhaOZRGJXIBb5iLntZbh3RYazIMQW+eKAWE=; b=jK79b4leViFTsxdbN3sl8LGKwCiabFvJt1b4Qqe89s0xhcwmSMNoGXvDcARTKR57gq OD+ghxib9z/vrSdgW2cg6NmjNhTqdTUlPFkuF4xnKkpf5bC2RGjiaSuiNwkWYHwmwz8i 61GQeL8c91Lj6zy5WoDdWXh8V0RNkSposCSuU= 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=biPz4oPLLTDLRyC/yQAOyyWUhPfhuD/JYHI0aVuPn+3atALgsjFJDaBhPNStWiZFMa Lh9VpOt/BBLKlVg1aEJ8HIQm1UEGB3Tb0ROGYAQ/TzI8vy5EEsgAXUgdWSUOgn4HCbp8 uOGR3skAa5B8PbGp/OFdfR2ClkVQRsL/5pBUU= Received: by 10.142.139.14 with SMTP id m14mr1890258wfd.100.1235379115112; Mon, 23 Feb 2009 00:51:55 -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 22sm8995801wfg.3.2009.02.23.00.51.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 00:51:54 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Mon, 23 Feb 2009 00:52:32 -0800 Date: Mon, 23 Feb 2009 00:52:32 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) Message-ID: <20090223085232.GA6492@hrair> References: <20090212173743.GD3652@comet> <20090212180350.0d9a9df5@snowcone> <1235037961.13198.779.camel@localhost> <20090219125124.33eaa66c@snowcone> <1235077892.13198.1923.camel@localhost> <20090222171658.278ae167@halo.dirtyepic.sk.ca> <49A1E1CB.1000806@gentoo.org> <20090222234800.29d64b8d@snowcone> <49A206A7.3050604@gentoo.org> <1235378286.31617.6.camel@neuromancer.neuronics-tp.ch> 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="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <1235378286.31617.6.camel@neuromancer.neuronics-tp.ch> User-Agent: Mutt/1.5.16 (2007-06-09) X-Archives-Salt: 9727d502-67a2-42de-8853-a60089b2a0b3 X-Archives-Hash: 7113b1c8d4f66529db0cc916d0a2d415 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 23, 2009 at 09:38:06AM +0100, Tiziano M??ller wrote: > > What is proposed in glep-55 seems to aim to solve both issues at the=20 > > same time (it isn't stated) by switching file extension every time the= =20 > > eapi is changed. This is slightly against the principle of the least=20 > > surprise and apparently is disliked by enough people to lead the=20 > > situation to be discussed in the council. > >=20 >=20 > Instead of switching file extension every time the eapi is changed you > could also increment it only when a new EAPI breaks sourcing the ebuild > compared to the requirements of the prior EAPI. > (This way you'd in fact split EAPI into a major- and a minor-version.) Complicates the implementation (annoying), but more importantly=20 negates one of the features of g55- being able to tell via the=20 extension if the manager supports that EAPI. Honestly, the issue isn't breaking sourcing (literally unable to=20 source it) of the ebuild as much as sourcing it *wrong*- simplest=20 example, new metadata key is added in eapi 1.3, compliant=20 implementations have to pull that key out of the env and put it in the=20 cache. Sourcing on the surface, would succeed- but the results would=20 be worthless (it'd basically be similar to the situation now). ~brian --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmiY88ACgkQsiLx3HvNzge3pQCgxbON8zzgUKMcj83Mp9rovxg1 EgUAnigulvwpA0af26RboqcEhT69I+1W =Qyh8 -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s--