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 1LcApx-0001w4-QQ for garchives@archives.gentoo.org; Wed, 25 Feb 2009 03:53:34 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 68FBCE0427; Wed, 25 Feb 2009 03:53:31 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 434CAE0427 for ; Wed, 25 Feb 2009 03:53:31 +0000 (UTC) Received: from sapphire (atlnts.org [85.222.29.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id AD2CF64B55 for ; Wed, 25 Feb 2009 03:53:30 +0000 (UTC) From: Dawid =?utf-8?q?W=C4=99gli=C5=84ski?= To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives Date: Wed, 25 Feb 2009 04:53:16 +0100 User-Agent: KMail/1.9.9 References: <49A472E3.1010204@gentoo.org> In-Reply-To: <49A472E3.1010204@gentoo.org> Organization: Gentoo Linux 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: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200902250453.17278.cla@gentoo.org> X-Archives-Salt: ec30b7a0-6cc9-420a-946d-87e6544a7a62 X-Archives-Hash: d9236df85973f026eeedfb62c53fba54 On Tuesday 24 of February 2009 23:21:23 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 :) > > My notes so far: > > 1) Status quo > - does not allow changing inherit > - bash version in global scope > - global scope in general is quite locked down > > 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 All of this are ok for me, though the first shot is my preffered one since= =20 it's the most human readable and the rest would be mostly seen as the packa= ge=20 version. > > 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) I don't see this as the best solution. > 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 Nah. Scanning portage tree in this place would be more painful than it's=20 currently. > c) .ebuild in current directory > - needs one year wait > > Regards, > Petteri