Re: [gentoo-portage-dev] [Request] Allow emerge to continue emerging unaffected packages on failure.

[Brian]

There are a few emerge wrapper scripts that do what you want.  emwrap.sh
is one, I believe update-world or named something like that is another.
Also (I'm prejudiced here) porhole is a portage gui frontend that queues
up the packages individually and lets you pause, move queue entries,
restart the queue, edit USE flags, etc..  The upgrades view also
separates all upgradeable packages into system, sets, world,
dependencies and lets you choose the ones to upgrade.

On Sat, 2008-06-07 at 11:13 -0400, Jason Cipriani wrote:
> 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
>
-- 
Brian <dol-sen@×××××.net>

-- 
gentoo-portage-dev@l.g.o mailing list