1 |
On Sat, 2003-12-06 at 19:39, George Shapovalov wrote: |
2 |
> Hm, isn't it a bit too late to change ebuild format, with us sitting on 7000+ |
3 |
> ebuilds? The only reasonable way to do so is to make it structurally |
4 |
> compatible and create a converter tool. |
5 |
|
6 |
It would be very difficult to get good results from a converter tool, |
7 |
due to the many complexities of ebuild parsing. |
8 |
|
9 |
> But then I don't really see the problem with present format. |
10 |
|
11 |
You just explained how much of a chore it would be to convert from |
12 |
ebuild to something else. Doesn't this point to a weakness in the syntax |
13 |
of ebuilds themselves? I mean, if they were more formally defined, they |
14 |
could be converted to XML or anything else without much effort. |
15 |
|
16 |
> bash involvment |
17 |
> is really necessary only during the pkg_* and src_* steps, when a lot of |
18 |
> other stuff is going to happen anyway, so this is hardly a bottleneck. |
19 |
|
20 |
This isn't an informed comment :) Portage depends on bash for extraction |
21 |
of metadata as well. Extraction of metadata is *the* Portage bottleneck. |
22 |
|
23 |
> To get |
24 |
> definitions of various vars and dependency information out is trivial and can |
25 |
> be done in anything. That bash is involved in this step at present is |
26 |
> unfortunate, but there were reasons for it and it definitely may be undone |
27 |
> even for the present portage. |
28 |
|
29 |
If it were trivial we would have done it already. The only way to "undo" |
30 |
the dependence on bash is to make seemingly arbitrary rules of what is |
31 |
legal and not legal to type inside ebuilds. This leads to a lot of |
32 |
strange rules (such as rules about where you can and can't use variable |
33 |
expansion, and where you can and can't use bash conditionals) and makes |
34 |
ebuild-writing a tricky process. We already have some of these rules in |
35 |
effect, and it makes ebuild-writing a bit trickier than it should be. |
36 |
|
37 |
We don't want ebuild-writing to be tricky, so the solution is to |
38 |
architect a way to represent ebuild data in a way that is more useful to |
39 |
portage-ng and more natural for ebuild-ng writers. |
40 |
|
41 |
Regards, |
42 |
|
43 |
Daniel |