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