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 1LcBRm-0006kw-Go for garchives@archives.gentoo.org; Wed, 25 Feb 2009 04:32:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 51695E03F5; Wed, 25 Feb 2009 04:32:35 +0000 (UTC) Received: from mailfilter11.ihug.co.nz (mailfilter11.ihug.co.nz [203.109.136.11]) by pigeon.gentoo.org (Postfix) with ESMTP id D4655E03F5 for ; Wed, 25 Feb 2009 04:32:34 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0BAOVXpEl2XGXQ/2dsb2JhbAAI11qEEQaDWw X-IronPort-AV: E=Sophos;i="4.38,263,1233486000"; d="scan'208";a="166518927" Received: from 118-92-101-208.dsl.dyn.ihug.co.nz (HELO [10.1.1.3]) ([118.92.101.208]) by smtp.mailfilter5.ihug.co.nz with ESMTP; 25 Feb 2009 17:32:18 +1300 Message-ID: <49A4C9CC.1060904@gentoo.org> Date: Wed, 25 Feb 2009 17:32:12 +1300 From: Alistair Bush 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> In-Reply-To: <49A472E3.1010204@gentoo.org> X-Enigmail-Version: 0.95.7 OpenPGP: url= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 9bc37d12-9a4e-46b3-afdc-d3e71ece082b X-Archives-Hash: 128b13a90d98ff43d402dc7a702af746 Petteri R=C3=A4ty wrote: > Let's try something new. I would like to get opinions from as many > people as possible about GLEP 55 and alternatives listed here in order > to get some idea what the general developer pool thinks. Everyone is > only allowed to post a single reply to this thread in order to make it > easy to read through. The existing thread should be used for actual > discussion about the GLEP and the alternatives. This should be a useful > experiment to see if we can control ourselves :) >=20 Thank you Petteri. I knew there was a reason I voted for you. >=20 > 2) EAPI in file extension > - Allows changing global scope and the internal format of the ebuild > a) .ebuild- > - ignored by current Portage > b) ..ebuild > - current Portage does not work with this > c) .. > - ignored by current Portage a) then c). I personally think b) is a bad idea that will just slow the implementation of this even more. >=20 > 3) EAPI in locked down place in the ebuild > - Allows changing global scope > - EAPI can't be changed in an existing ebuild so the PM can trust > the value in the cache > - Does not allow changing versioning rules unless version becomes a > normal metadata variable > * Needs more accesses to cache as now you don't have to load older > versions if the latest is not masked > a) > b) new subdirectory like ebuilds/ > - we could drop extension all together so don't have to argue about > it any more > - more directory reads to get the list of ebuilds in a repository > c) .ebuild in current directory > - needs one year wait If it really comes to it b)? Tho it leaves a bad taste in my mouth. >=20 > Regards, > Petteri >=20