Gentoo Archives: gentoo-portage-dev

From: Jason Cipriani <jason.cipriani@×××××.com>
To: gentoo-portage-dev@l.g.o
Subject: [gentoo-portage-dev] [Request] Allow emerge to continue emerging unaffected packages on failure.
Date: Sat, 07 Jun 2008 15:13:17
Message-Id: c09049bf0806070813m369bca7al1b49a77f28324c33@mail.gmail.com
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

Replies