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. > > 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/<eapi-name>/ which would contain a python script named > <eapi-name>.py. If not already loaded, that plugable eapi would be > loaded before processing the ebuild. > > That way, there is no outdated ebuild format. There is just a default > format which is the actual format. > > It could also be an XML defining the ebuild's build sequence and other > particularities a group of ebuild could have. Few questions; 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, this would add it (livecd/stage* potentially needing adjustment as a result). B) EAPI is pretty much bash env template switching; xml/python plugins don't help in that respect, although a python plugin for that eapi level may be added at some point (right now it's not required for the eapi v0/v1 python side components).
I am worried, long term mind you, in tracking the differences between eapi levels and keeping the code clean. My thought for way down the line when an eapi level has long since gone unused is to break it out 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 sweating over till rewrite is usable (priorities), but that's the long term intention for EAPI. Beyond that, the question of what needs to be tracked outside of python/bash code (what would be stuck in the suggested xml) should also be clarified, since I'm not seeing what all would be jammed in there. ~harring
pgprFuJJx6RR1.pgp
Description: PGP signature
