From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1J4ZMA-00009U-GS for garchives@archives.gentoo.org; Tue, 18 Dec 2007 10:07:23 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lBIA6Twu024634; Tue, 18 Dec 2007 10:06:29 GMT Received: from smtp.ferdyx.org (170.Red-213-96-222.staticIP.rima-tde.net [213.96.222.170]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lBIA44rP021285 for ; Tue, 18 Dec 2007 10:04:04 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.ferdyx.org (Postfix) with ESMTP id EE81D8D306 for ; Tue, 18 Dec 2007 11:07:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at ferdyx.org Received: from smtp.ferdyx.org ([127.0.0.1]) by localhost (tungsteno.ferdyx.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5miMk5I0mbVw for ; Tue, 18 Dec 2007 11:07:15 +0100 (CET) Received: from localhost (unknown [213.121.151.206]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ferdyx.org (Postfix) with ESMTP id CEE578D305 for ; Tue, 18 Dec 2007 11:07:14 +0100 (CET) Date: Tue, 18 Dec 2007 10:03:56 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) Message-ID: <20071218100356.3a78bf8d@blueyonder.co.uk> In-Reply-To: <20071218093630.GA29854@gentoo.org> References: <200712172320.01988.peper@gentoo.org> <47671006.2020808@gentoo.org> <20071218001855.78c1864c@blueyonder.co.uk> <476714BA.3070202@gentoo.org> <20071218003938.62df389e@blueyonder.co.uk> <20071218093630.GA29854@gentoo.org> X-Mailer: Claws Mail 3.1.0 (GTK+ 2.12.1; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/18RcNPAdzpri.74DwJThtIR"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: dd26b86b-cc98-4d93-9be2-f11ada7fd89a X-Archives-Hash: 0ff7f3c9a8001bb439c00815e0487acc --Sig_/18RcNPAdzpri.74DwJThtIR Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 18 Dec 2007 10:36:30 +0100 Fabian Groffen wrote: > On 18-12-2007 00:39:38 +0000, Ciaran McCreesh wrote: > > An EAPI is not limited to a numeric name. We could call the next > > EAPI "cabbage" if we wanted to. There're already various > > experimental EAPIs that don't use pure numbers (for example, > > "paludis-1"). > >=20 > > (Sometimes I think the next EAPI *should* be called "cabbage", if > > only because it'll help disabuse people of the notion that EAPIs are > > orderable...) >=20 > While I feel there has been given little to no attention to what > EAPI's really are and how they relate to each other, I prefer to go > this route myself as well. The EAPI "name" should represent the > feature(s) it adds. EAPIs don't correspond to features either though. > However, because "features" need not to include previous ones (why > would they?), in the Prefix branch of Portage I implemented EAPI to > be a space separated list. I merely did this because EAPI=3D1 ebuilds > needed to be tagged as such in an EAPI=3D"prefix" ebuild, and the > features EAPI=3D"prefix" adds are ortogonal on the features EAPI=3D0 or > EAPI=3D1 ... provides. As a result I now have EAPI=3D"prefix 1" ebuilds. >=20 > Since you seem to argue here that EAPIs are not orderable, I get the > impression you imply these "combinations" of EAPIs to be desirable. > In that case, what would the extension of the ebuild be like? Combinations of features and rules is desirable. An EAPI can be thought of as a collection of said features and rules (and that's how EAPIs are worded in PMS, and largely how they're implemented in Paludis). But developers shouldn't really be picking and choosing at that level themselves -- adding new EAPIs that merely add one thing to a previous EAPI (as 1 did to 0) is cheap. Plus, we're back to the whole combination issue raised with eclasses. There's no guarantee that features from different EAPIs can be combined in any sensible way. For example (and I hope this doesn't happen...) EAPI 2 might add a new IDEPEND variable, and then EAPI 3 might replace *DEPEND with the single DEPENDENCIES + labels. You couldn't then say that you want both IDEPEND and DEPENDENCIES, since they're largely mutually incompatible. --=20 Ciaran McCreesh --Sig_/18RcNPAdzpri.74DwJThtIR Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHZ5sM96zL6DUtXhERAmXiAJ4zVdCi/CWfrMwfxSVeXVMCygov5QCcDozH c+mEP30MUd/fbM+lcnWs35c= =iF2L -----END PGP SIGNATURE----- --Sig_/18RcNPAdzpri.74DwJThtIR-- -- gentoo-dev@gentoo.org mailing list