1 |
Michael Orlitzky wrote: |
2 |
> On 4/22/20 1:29 PM, Dale wrote: |
3 |
>> Some may recall my thread about emerge only using one core when doing |
4 |
>> it's build list. As was discussed in that thread, it would be really |
5 |
>> difficult to build that list in pretty much any language because it just |
6 |
>> isn't set up to do that, the tree itself it seems. While I'd like |
7 |
>> emerge to be able to use more than one core, it may be faster but it |
8 |
>> might also fall more often to which would waste more time than using |
9 |
>> multiple cores would save. In other words, a lot of work with little or |
10 |
>> no benefit. |
11 |
>> |
12 |
> Dependency resolution is indeed a (formally) hard problem. Solving the |
13 |
> traveling salesman problem is also hard. Solving the traveling salesman |
14 |
> problem while being punched in the face is even harder. When I complain |
15 |
> about portage being slow, what I mean is that I want to stop being |
16 |
> punched in the face so that I can concentrate all of my energy on the |
17 |
> underlying hard problem. |
18 |
> |
19 |
> |
20 |
|
21 |
I'll freely admit that my knowledge of the inner workings of |
22 |
emerge/portage is tiny. Even with what little I know, I'd hate to know |
23 |
I had to do what emerge does with paper and pencil. I suspect that |
24 |
upgrading one package that has even just a few dependencies would be a |
25 |
very slow and repetitive process. Doing a major upgrade that is maybe a |
26 |
one month jump, complete with several KDE upgrades, it could take weeks |
27 |
to do all that by hand. When people say magic is what emerge does, it |
28 |
is likely closer than some think. The only thing that isn't magic, the |
29 |
error output. |
30 |
|
31 |
I feel sorry for the person/people who actually write the code for |
32 |
emerge. Heck, making a ebuild from scratch is likely bad enough. I |
33 |
can't imagine tinkering with emerge itself. |
34 |
|
35 |
Thank goodness it isn't me. ;-) |
36 |
|
37 |
Dale |
38 |
|
39 |
:-) :-) |