From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1E8kwy-0002io-45 for garchives@archives.gentoo.org; Fri, 26 Aug 2005 20:37:20 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j7QKZ9c1006212; Fri, 26 Aug 2005 20:35:09 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j7QKXRAF011554 for ; Fri, 26 Aug 2005 20:33:27 GMT Received: from cpe-65-26-255-237.wi.res.rr.com ([65.26.255.237] helo=nightcrawler) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1E8kuX-00060m-L0 for gentoo-dev@lists.gentoo.org; Fri, 26 Aug 2005 20:34:53 +0000 Date: Fri, 26 Aug 2005 15:32:42 -0500 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] EAPI Message-ID: <20050826203242.GS1701@nightcrawler> References: <1125085775.16733.55.camel@localhost> 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; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Uw+RRa3pmtkgiNaD" Content-Disposition: inline In-Reply-To: <1125085775.16733.55.camel@localhost> User-Agent: Mutt/1.5.8i X-Archives-Salt: 6a8a8a2d-9522-41ff-923e-8d0102df641f X-Archives-Hash: e439f086a0b667e332ce0f5aa5b81881 --Uw+RRa3pmtkgiNaD Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 26, 2005 at 03:49:35PM -0400, Kristian Benoit wrote: > On the EAPI subject Brian just brought back, I had this idea that we > could use the same approch XML took with HTML. >=20 > The ebuild could define which EAPI to use, but instead beiing a version, > the EAPI would be an ebuild API definition. The equivalent to the XML's > dtd. The ebuild could point to a directory named > $PORTDIR/eapi// which would contain a python script named > .py. If not already loaded, that plugable eapi would be > loaded before processing the ebuild. >=20 > That way, there is no outdated ebuild format. There is just a default > format which is the actual format. >=20 > It could also be an XML defining the ebuild's build sequence and other > particularities a group of ebuild could have. Few questions;=20 A) what does xml bring to the table explicitly that is needed? remember portage doesn't have a hard dep on xml parsing libs yet,=20 this would add it (livecd/stage* potentially needing adjustment as=20 a result). B) EAPI is pretty much bash env template switching; xml/python plugins=20 don't help in that respect, although a python plugin for that eapi=20 level may be added at some point (right now it's not required for=20 the eapi v0/v1 python side components). I am worried, long term mind you, in tracking the differences between=20 eapi levels and keeping the code clean. My thought for way down the=20 line when an eapi level has long since gone unused is to break it out=20 of portage and into it's own package as a plugin. Specifics of it haven't yet gotten to, mainly because it's not worth=20 sweating over till rewrite is usable (priorities), but that's the long=20 term intention for EAPI. Beyond that, the question of what needs to be tracked outside of=20 python/bash code (what would be stuck in the suggested xml) should=20 also be clarified, since I'm not seeing what all would be jammed in=20 there. ~harring --Uw+RRa3pmtkgiNaD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDD3xpvdBxRoA3VU0RAj32AKCOGSNUlNPuehq7PeBTMZ9MUItjCgCeI9u5 ICEwPahGQ7ag5CmkdSK1i4E= =ep0Z -----END PGP SIGNATURE----- --Uw+RRa3pmtkgiNaD-- -- gentoo-dev@gentoo.org mailing list