| 1 |
Wouldn't it be wise then to allow for multiple ebuild formats through |
| 2 |
plug-ins? Like you say, a considerable amount of ebuilds need nothing |
| 3 |
more than to run configure, make, and make install. |
| 4 |
|
| 5 |
Then there are those ebuilds that are a few hundred lines (or gasp more) |
| 6 |
of bash script that would benefit from something more structured. What |
| 7 |
that something is I honestly don't know. But at least with the plug-able |
| 8 |
ebuild format, we could retain compatibility with the current ebuilds, |
| 9 |
and slowly phase them into something more appropriate. |
| 10 |
|
| 11 |
Just my $0.02. |
| 12 |
|
| 13 |
- Ray Russell Reese III [ freenode:anti ] |
| 14 |
|
| 15 |
On Sat, 2003-12-06 at 21:39, George Shapovalov wrote: |
| 16 |
> On Saturday 06 December 2003 17:44, Jason Stubbs wrote: |
| 17 |
> > It's not getting ahead of things! That's a requirement that's not |
| 18 |
> > covered yet. "Package definition should be powerful but simple with a |
| 19 |
> > small learning curve" or something to that effect. |
| 20 |
> |
| 21 |
> Hm, isn't it a bit too late to change ebuild format, with us sitting on 7000+ |
| 22 |
> ebuilds? The only reasonable way to do so is to make it structurally |
| 23 |
> compatible and create a converter tool. Even then this is a major endeavor |
| 24 |
> that would require a very good reason (nothing short of deadly limitations of |
| 25 |
> the present format, which I woudn't say is the case). Furthermore, this would |
| 26 |
> require wide publicity and even votes if we do not want to alienate users, as |
| 27 |
> this is the change that definitely will affect them (take a look at number of |
| 28 |
> new ebuild submissions ;)). |
| 29 |
> |
| 30 |
> But then I don't really see the problem with present format. bash involvment |
| 31 |
> is really necessary only during the pkg_* and src_* steps, when a lot of |
| 32 |
> other stuff is going to happen anyway, so this is hardly a bottleneck. To get |
| 33 |
> definitions of various vars and dependency information out is trivial and can |
| 34 |
> be done in anything. That bash is involved in this step at present is |
| 35 |
> unfortunate, but there were reasons for it and it definitely may be undone |
| 36 |
> even for the present portage. |
| 37 |
> |
| 38 |
> George |
| 39 |
> |
| 40 |
> |
| 41 |
> |
| 42 |
> -- |
| 43 |
> gentoo-portage-dev@g.o mailing list |
| 44 |
> |
| 45 |
|
| 46 |
|
| 47 |
-- |
| 48 |
gentoo-portage-dev@g.o mailing list |
Archives