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 1LcVka-0003jF-Mg for garchives@archives.gentoo.org; Thu, 26 Feb 2009 02:13:24 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8177BE0369; Thu, 26 Feb 2009 02:13:21 +0000 (UTC) Received: from ironclad.mail.utexas.edu (ironclad.mail.utexas.edu [146.6.25.7]) by pigeon.gentoo.org (Postfix) with ESMTP id 5DA55E0369 for ; Thu, 26 Feb 2009 02:13:21 +0000 (UTC) X-IronPort-MID: 1052095722 Received: from wb5-a.mail.utexas.edu ([128.83.126.142]) by ironclad.mail.utexas.edu with ESMTP; 25 Feb 2009 20:13:21 -0600 Received: (qmail 49600 invoked from network); 26 Feb 2009 02:13:20 -0000 Received: from cpe-72-179-50-92.austin.res.rr.com (HELO ?192.168.1.116?) (rpinjala@72.179.50.92) by wb5.mail.utexas.edu with (RC4-MD5 encrypted) ESMTPSA; 26 Feb 2009 02:13:20 -0000 Message-ID: <49A5FAC0.7040509@p-static.net> Date: Wed, 25 Feb 2009 20:13:20 -0600 From: Ravi Pinjala User-Agent: Thunderbird 2.0.0.19 (X11/20081231) 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: d44b66d6-87d2-4480-9970-9af6b38c41db X-Archives-Hash: 4454ab42cbbef3c3029b12c2b639019a 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 > My notes so far: >=20 > 1) Status quo > - does not allow changing inherit > - bash version in global scope > - global scope in general is quite locked down >=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 >=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 >=20 > Regards, > Petteri >=20 Another option which I haven't seen mentioned here yet would be to just specify that the method of finding the EAPI depends on the file extension. Then, anything with a .ebuild extension can be sourced with bash to find the EAPI, and ebuild formats incompatible with that could use another file extension. This would work with current package managers, while still providing a mechanism for incompatible format changes in the future. It's also aesthetically nicer than current proposals, since the file extension would indicate something about the contents of the file. Or, to put it another way, this would formalize the difference between the ebuild format (which is currently bash throughout the tree), and the EAPI. I don't think anybody would oppose a file extension change for a format change, as opposed to an EAPI change. --Ravi