On Sat, 2003-12-06 at 19:39, George Shapovalov wrote:
> Hm, isn't it a bit too late to change ebuild format, with us sitting on 7000+ 
> ebuilds? The only reasonable way to do so is to make it structurally 
> compatible and create a converter tool.

It would be very difficult to get good results from a converter tool,
due to the many complexities of ebuild parsing.

> But then I don't really see the problem with present format.

You just explained how much of a chore it would be to convert from
ebuild to something else. Doesn't this point to a weakness in the syntax
of ebuilds themselves? I mean, if they were more formally defined, they
could be converted to XML or anything else without much effort. 

> bash involvment 
> is really necessary only during the pkg_* and src_* steps, when a lot of 
> other stuff is going to happen anyway, so this is hardly a bottleneck.

This isn't an informed comment :) Portage depends on bash for extraction
of metadata as well. Extraction of metadata is *the* Portage bottleneck.

> To get 
> definitions of various vars and dependency information out is trivial and can 
> be done in anything. That bash is involved in this step at present is 
> unfortunate, but there were reasons for it and it definitely may be undone 
> even for the present portage.

If it were trivial we would have done it already. The only way to "undo"
the dependence on bash is to make seemingly arbitrary rules of what is
legal and not legal to type inside ebuilds. This leads to a lot of
strange rules (such as rules about where you can and can't use variable
expansion, and where you can and can't use bash conditionals) and makes
ebuild-writing a tricky process. We already have some of these rules in
effect, and it makes ebuild-writing a bit trickier than it should be.

We don't want ebuild-writing to be tricky, so the solution is to
architect a way to represent ebuild data in a way that is more useful to
portage-ng and more natural for ebuild-ng writers.

Regards,

Daniel