1 |
I do not always have the chance (or sometimes the desire) to update packages |
2 |
often enough to keep the updates small. So frequently, when I emerge -u |
3 |
world, for example, there's 100-200 packages to update. This also can happen |
4 |
if I change certain USE flags and use -N. |
5 |
|
6 |
The problem is, since it's time consuming it's generally something I need to |
7 |
run over night to avoid any down time. Inevitably, when I come back in the |
8 |
morning, however, I'll see something like (I've trimmed off the [ok] to keep |
9 |
the lines short): |
10 |
|
11 |
>>> Emerging (12 of 183) net-print/cups-1.3.7-r1 to / |
12 |
* cups-1.3.7-source.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... |
13 |
* checking ebuild checksums ;-) ... |
14 |
* checking auxfile checksums ;-) ... |
15 |
* checking miscfile checksums ;-) ... |
16 |
* checking cups-1.3.7-source.tar.bz2 ;-) ... |
17 |
>>> cfg-update-1.8.2-r1: Skipping checksum index updating... |
18 |
|
19 |
* In order to have cups working with avahi zeroconf support, you need |
20 |
* to have net-dns/avahi emerged with "mdnsresponder-compat" in your USE |
21 |
* flag. Please add that flag, re-emerge avahi, and then emerge cups again. |
22 |
|
23 |
|
24 |
In that example, the fix is simple -- follow the instructions and try emerge |
25 |
-u again. Unfortunately that also means it costs another day, as I can't |
26 |
really do that again until the next evening (and, in rarer cases, it leaves |
27 |
the system unstable if it's in a half-updated state that breaks certain |
28 |
dependencies). For every package this happens to, that is one extra day. In |
29 |
most cases this happens to 1-4 packages, meaning I generally have to reserve |
30 |
the better part of a week to update packages. |
31 |
|
32 |
If package A depends on package B, it is reasonable to fail and not build |
33 |
package A if package B fails. However, I am 99% sure that the remaining 171 |
34 |
packages I had to update did not depend on cups (to use that example). It is |
35 |
not reasonable for emerge to fail to update things like gcc and ati-drivers |
36 |
if cups fails. It is also not reasonable to stop emerge for a reason like |
37 |
"another package may use avahi and that's the one you need to fix" -- as in |
38 |
that case a simple emerge -N would take care of the minimal set of packages |
39 |
effected by that change. |
40 |
|
41 |
What I would like to see is a command line option to emerge that enables the |
42 |
following simple behavior: |
43 |
|
44 |
- If package A fails to build, display the error and move package A and |
45 |
all packages that depend on it to the *end* of the update queue, but do not |
46 |
exit. |
47 |
- If a package fails to build for the second time (i.e. it's already been |
48 |
tried and moved), *then* display error and exit as normal. |
49 |
|
50 |
I can think of other more complex behaviors that might make this more |
51 |
"convenient", but I believe anything more than that is unnecessary. I think |
52 |
this is a simple solution that mitigates most of the problem. That will |
53 |
allow the unaffected packages (which, in my experience, is the vast majority |
54 |
of packages in most cases) to continue building, and effectively defers the |
55 |
error until the last possible minute. Then a user running emerge fixes the |
56 |
error and reruns emerge; but only the smaller set of affected packages still |
57 |
remains to be built. |
58 |
|
59 |
For me, this would reduce updating my system from a week-long process to |
60 |
just one day -- update the majority overnight, and if any fail it's likely |
61 |
that the remaining packages can be fixed and updated in a reasonable amount |
62 |
of time the following day. |
63 |
|
64 |
Jason |