1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Duncan wrote: |
5 |
> For the first 100 or so packages, it worked quite well. However, about |
6 |
> there, maybe package 120 or so, so about 20% of the way thru, it reverted |
7 |
> to doing them one-at-a-time again. I'm now on package #279 and it's |
8 |
> still doing them only one at a time, and this has included stuff like the |
9 |
> xorg-docs (IIRC) package, that really shouldn't be pre-deps for stuff |
10 |
> that has come since, so /something/ else should have been trying to |
11 |
> merge, as long as load-average stays low, as it has much of the time (I |
12 |
> have MAKEOPTS="-j -l20" so it's not going to be low all the time). |
13 |
> |
14 |
> Is this a known issue still being worked on, perhaps due to the limits of |
15 |
> the package dependency and scheduling resolution such that it can't |
16 |
> handle a full world remerge and defaults back to one-at-a-time after it |
17 |
> reaches the extent of its mapping, or is this a new bug? |
18 |
|
19 |
The current algorithm is intentionally as conservative as possible |
20 |
in the sense that it will not build given package in parallel if |
21 |
there are any packages in it's subgraph of deep dependencies |
22 |
scheduled to be merged. We can add one or more options to control |
23 |
the criteria for choosing packages. Those options will modify the |
24 |
behavior of Scheduler._choose_pkg(). |
25 |
|
26 |
There are a couple of reasons for the current conservative |
27 |
behavior. In many cases the conservative behavior is beneficial |
28 |
(avoids breakage) in order to ensure that a package's subgraph of |
29 |
deep dependencies is up to date before building the package itself. |
30 |
In addition, the conservative behavior lessens the need to be |
31 |
concerned about "invariance" requirements like those discussed in |
32 |
bug 232990 [1]. |
33 |
|
34 |
> Also, a little monitoring utility that could be run in another terminal |
35 |
> and just list and update all the currently merging packages, and any that |
36 |
> had failed to merge, so I could take a look at them while the system is |
37 |
> still working on the rest, would be quite useful. I tried watch ls -d |
38 |
> $PORTAGE_TMPDIR/*/* and it starts to work, but of course starts to error |
39 |
> in a few seconds when the first package completes since the *s are |
40 |
> resolved initially. With a bit of work I'm sure can get something simple |
41 |
> working, but it'd be nice if there were a pre-made utility to do it. |
42 |
> Maybe there is and I just don't know about it yet? =8^) |
43 |
|
44 |
I'm not aware of any tool like that yet. Such a tool should probably |
45 |
use the hidden lock file located in the parent directory of a build |
46 |
directory in order to detect an active build. In the future I plan |
47 |
to have a daemon process to allow cooperation between multiple |
48 |
emerge invocations, for things like bug 177311 [2]. Once that's |
49 |
implemented, there will be a way to query the daemon for information |
50 |
about running builds. |
51 |
|
52 |
> Finally... I was rather confused the first time at just one job an |
53 |
> install took a bit, as that's apparently not counted as "running", so it |
54 |
> appeared nothing was going on for a bit. Maybe an "installing" count as |
55 |
> well would be useful... and prevent that confusion. |
56 |
|
57 |
There used to be a "merges" count in the status display but somebody |
58 |
thought it was confusing (darkside/Jeremy Olexa) and I decided that |
59 |
it wasn't interesting enough to be worthy of it's display space so I |
60 |
removed it. I guess we can add it back if there's space and demand |
61 |
for it. Maybe it should only be shown when the job count drops to zero? |
62 |
|
63 |
Zac |
64 |
|
65 |
[1] http://bugs.gentoo.org/show_bug.cgi?id=232990 |
66 |
[2] http://bugs.gentoo.org/show_bug.cgi?id=177311 |
67 |
-----BEGIN PGP SIGNATURE----- |
68 |
Version: GnuPG v2.0.9 (GNU/Linux) |
69 |
|
70 |
iEYEARECAAYFAkiLupEACgkQ/ejvha5XGaP8KQCffKnpIiplEioyP4JOlD8HGD21 |
71 |
Q2QAnAroP5voKc8zyXcCFArPxrYjsec3 |
72 |
=3epU |
73 |
-----END PGP SIGNATURE----- |