1 |
Howdy, |
2 |
|
3 |
I don't recall seeing the thread on the forums but it sort of sounds a |
4 |
lot like what I was reading on -dev as to why it is not. Basically, it |
5 |
would be a complex and difficult piece of code. According to some, it |
6 |
could even create problems that don't exist now, depending on what |
7 |
dependencies may pop into the process. |
8 |
|
9 |
It would be nice IF it could be done and really help with the time it |
10 |
takes to calculate but it sounds like it might not even help much if it |
11 |
was coded that way. I guess it won't be done anytime soon. It seems |
12 |
like for good reason but it would be nifty. |
13 |
|
14 |
I might add, I think that forum thread was way earlier than the posts on |
15 |
-dev. I think the discussion on -dev was only a few years ago. All in |
16 |
all, the emerge command has come a long ways since I started uses Gentoo |
17 |
back in 2003. |
18 |
|
19 |
Thanks for the info. |
20 |
|
21 |
Dale |
22 |
|
23 |
:-) :-) |
24 |
|
25 |
|
26 |
|
27 |
Woohyung Jeon wrote: |
28 |
> I can't be sure whether these links will help, but there were conversations. |
29 |
> |
30 |
> https://forums.gentoo.org/viewtopic-t-866779-start-0.html |
31 |
> https://www.reddit.com/r/Gentoo/comments/68psrz/why_does_emerge_calculate_dependencies_on_a/ |
32 |
> |
33 |
> On Fri, Dec 13, 2019 at 6:44 AM Dale <rdalek1967@×××××.com> wrote: |
34 |
>> james wrote: |
35 |
>>> On 12/9/19 1:31 AM, Dale wrote: |
36 |
>>>> Howdy, |
37 |
>>>> |
38 |
>>>> I'm sure trying to get portage to do things in parallel would be a |
39 |
>>>> programmers nightmare.� It may not even be doable given how the |
40 |
>>>> tree is |
41 |
>>>> done or that the complexity of calculating all the options is just to |
42 |
>>>> much to run in parallel. |
43 |
>>> Hello Dale, |
44 |
>>> |
45 |
>>> Not sure this is what you are looking for, but it's pretty easy to set |
46 |
>>> up. |
47 |
>>> |
48 |
>>> |
49 |
>>> in my /etc/make.conf file I have this:: |
50 |
>>> |
51 |
>>> |
52 |
>>> MAKEOPTS="-j7 -l8" |
53 |
>>> |
54 |
>>> |
55 |
>>> so it does what you are looking for on larger upgrades. Some files |
56 |
>>> that do not compile properly, auto limit to one core. My understanding |
57 |
>>> is there are a variety of mechanism to achieve this. |
58 |
>>> |
59 |
>>> The kernel version/setting surely has more options, but they are |
60 |
>>> optimized according to the types of workloads and the scheduler you |
61 |
>>> have selected. YOU or anyone can waist weeks and months going down |
62 |
>>> that pathway. |
63 |
>>> |
64 |
>>> Then there are mechanisms to further refine how your system works. |
65 |
>>> |
66 |
>>> |
67 |
>>> It's a wide open area so read up a bit and find your comfort level. |
68 |
>>> |
69 |
>>> |
70 |
>>> hth, |
71 |
>>> James |
72 |
>>> |
73 |
>>> |
74 |
>> |
75 |
>> I have that type of setting already. What I was talking about is when |
76 |
>> you do a emerge -uaDN world and it is calculating what packages needs |
77 |
>> updating. When it is doing that, it only uses one core, thread I guess |
78 |
>> for those who have threads, which means having a multi-core CPU doesn't |
79 |
>> help speed things up. Basically, my question was about the emerge |
80 |
>> command itself not when it is actually compiling packages. |
81 |
>> |
82 |
>> I read where it was discussed on -dev a couple years or so ago. I'm not |
83 |
>> a coder but from what I could understand, it sounded really complicated |
84 |
>> to have the emerge command able to run calculations in parallel. It |
85 |
>> seems there is a couple things that just can not be done that way. |
86 |
>> |
87 |
>> Maybe one day. Just maybe. |
88 |
>> |
89 |
>> Dale |
90 |
>> |
91 |
>> :-) :-) |
92 |
>> |
93 |
> |