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