1 |
J. Roeleveld wrote: |
2 |
> Top posting? You? |
3 |
> |
4 |
> |
5 |
> On 13 December 2019 08:36:08 CET, Dale <rdalek1967@×××××.com> wrote: |
6 |
>> Howdy, |
7 |
>> |
8 |
>> I don't recall seeing the thread on the forums but it sort of sounds a |
9 |
>> lot like what I was reading on -dev as to why it is not. Basically, it |
10 |
>> would be a complex and difficult piece of code. According to some, it |
11 |
>> could even create problems that don't exist now, depending on what |
12 |
>> dependencies may pop into the process. |
13 |
>> |
14 |
>> It would be nice IF it could be done and really help with the time it |
15 |
>> takes to calculate but it sounds like it might not even help much if it |
16 |
>> was coded that way. I guess it won't be done anytime soon. It seems |
17 |
>> like for good reason but it would be nifty. |
18 |
>> |
19 |
>> I might add, I think that forum thread was way earlier than the posts |
20 |
>> on |
21 |
>> -dev. I think the discussion on -dev was only a few years ago. All in |
22 |
>> all, the emerge command has come a long ways since I started uses |
23 |
>> Gentoo |
24 |
>> back in 2003. |
25 |
>> |
26 |
>> Thanks for the info. |
27 |
> I do think it can be done and should make it quicker. |
28 |
> If done correctly, the hack of "backtracking" won't be needed anymore as well. |
29 |
> |
30 |
> Portage is a database and should be handled that way as well. Then for every package in the "install set" a thread can be started to check all the requirements. |
31 |
> For each requirement, if it is already met, fine. If not, a new thread to check that. Result of each is what is needed. Any conflicts can be identified and handled by the calling thread. |
32 |
> |
33 |
> This should scale, provided the entire tree can be loaded into memory quickly. |
34 |
> |
35 |
> -- |
36 |
> Joost |
37 |
> |
38 |
|
39 |
I top posted because the previous person did. I don't know what device |
40 |
they are using and thought it be easier for them. Yes, it does throw |
41 |
the order of things into reverse but as we know, some devices aren't |
42 |
logical. LOL |
43 |
|
44 |
I think part of the problem is that emerge was never intended to be |
45 |
multi-threaded. It reminds me of Firefox. I seem to recall several |
46 |
years ago the devs there practically started from scratch in order to |
47 |
fix some issues and make multi-threading work correctly. Yea, some |
48 |
complained about it breaking things and all but using the old code base |
49 |
could have resulted in a worse piece of software. I read all sorts of |
50 |
comments on the reasoning behind the drastic change. Sometimes, you |
51 |
just have to throw out the bath water and start with fresh water. I |
52 |
suspect that quite often, it is even easier to do so. |
53 |
|
54 |
If things keep getting more complex, I suspect at some point it will |
55 |
have to be done. Even with the limited knowledge I have of how emerge |
56 |
works, I feel sorry for that coder. They may have to invent a new slide |
57 |
rule. ;-) Still, emerge being 4 or 5 times faster would be nice. For |
58 |
those who have dozens of threads and even multi-CPU systems with lots of |
59 |
threads, it would be even faster. |
60 |
|
61 |
I do want to be clear. I'm not complaining about emerge. It does a |
62 |
awesome job, except for that cryptic error output sometimes. :/ I was |
63 |
sort of hoping to learn a bit and maybe even make someone think about a |
64 |
way to work around this. Even if it takes a year or two to get the |
65 |
brain fully engaged, it would be worth it. |
66 |
|
67 |
Speaking of backtracking, that's one reason mine takes so long. I have |
68 |
some settings set as defaults because it makes emerge resolve issues |
69 |
without having to set those options and starting it again. I think I |
70 |
have backtrack set to 100. I started with the default which is much |
71 |
lower but found that quite often it just wasn't deep enough. |
72 |
|
73 |
Interesting thread tho. |
74 |
|
75 |
Dale |
76 |
|
77 |
:-) :-) |