1 |
Crystalsun <crystalsun@××××××××××.com> writes: |
2 |
|
3 |
> Anyone thought about implementing Emerge in Common Lisp? |
4 |
I did. I know some other people did, too. |
5 |
|
6 |
> I guess it could be useful due to the interactiveness Common Lisp |
7 |
> provides |
8 |
Agree. |
9 |
|
10 |
> if emerge was written in Common Lisp, it could be possible to |
11 |
> interactively debug the error and continue the process |
12 |
Not neccesarily. ebuilds are still ebuilds, namely Unix shell |
13 |
scripts. Most of my problems come from them not from emerge per se. |
14 |
|
15 |
> I know it may sound ambitious |
16 |
It does. |
17 |
|
18 |
> but at least it seems like an interesting idea to me, would be great |
19 |
> if anyone has thoughts on this topic |
20 |
Portage is updated regularly. EAPI evolves. Try estimating how many |
21 |
man-hours are put into it. That will give you some perspective on |
22 |
man-hours needed to maintain another implementation. Make some research |
23 |
on existing attempts (Paludis). |
24 |
|
25 |
The most promising way in my amateur-ish opinion would be to localise |
26 |
some task which Portage is slow at, and try to reimplement it (100% |
27 |
correctly!) for immediate and hopefully long-lasting gains. At least |
28 |
that could provide the project with some momentum and attention early |
29 |
on. |
30 |
|
31 |
Another attractive goal would be the ability to resolve |
32 |
dependencies interactively. I'm not even where to start with this |
33 |
though. Maybe if user could increase the backtracking threshold |
34 |
(emerge --backtrack=n) without restarting the whole thing, that would |
35 |
already be worth it, who knows. That would require lazy search of some |
36 |
kind. |