| 1 |
Brian Harring <ferringb@g.o> wrote: |
| 2 |
> On Fri, Aug 26, 2005 at 03:49:35PM -0400, Kristian Benoit wrote: |
| 3 |
[snip] |
| 4 |
> > the EAPI would be an ebuild API definition. The equivalent to the XML's |
| 5 |
> > dtd. The ebuild could point to a directory named |
| 6 |
> > $PORTDIR/eapi/<eapi-name>/ which would contain a python script named |
| 7 |
[snip] |
| 8 |
> Few questions; |
| 9 |
> A) what does xml bring to the table explicitly that is needed? |
| 10 |
> remember portage doesn't have a hard dep on xml parsing libs yet, |
| 11 |
> this would add it (livecd/stage* potentially needing adjustment as |
| 12 |
> a result). |
| 13 |
|
| 14 |
If I read the idea correctly, it's not suggesting that Portage implement |
| 15 |
XML as a config engine; it's just using XML as an example. The analogy |
| 16 |
works just as well for SGML DTDs or C libraries. |
| 17 |
|
| 18 |
> B) EAPI is pretty much bash env template switching |
| 19 |
[snip] |
| 20 |
|
| 21 |
Perhaps the EAPI handling could be implemented using eclasses, rather |
| 22 |
than something in the deep, dark, python-based internals. |
| 23 |
|
| 24 |
-- |
| 25 |
That is not dead which can eternal lie, |
| 26 |
And with strange eons even death may die. |
| 27 |
-- The Call of Cthulu, II. The Tale of Inspector Legrasse |
Archives