FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Portage Developer

 
 
LinkBack Thread Tools
 
Old 06-07-2008, 03:13 PM
"Jason Cipriani"
 
Default Allow emerge to continue emerging unaffected packages on failure.

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
 
Old 06-07-2008, 07:54 PM
Zac Medico
 
Default Allow emerge to continue emerging unaffected packages on failure.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason Cipriani wrote:
> 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.

In portage-2.1.5.3 there are some changes to the --skipfirst
behavior that are helpful for situations like this. For example, you
can do something like this:

emerge --update --deep world ; while [ $? != 0 ] ; do emerge
- --resume --skipfirst ; done

With the new --skipfirst behavior, any packages with unsatisfied
dependencies will be automatically dropped. You can also mask
packages via package.mask and --skipfirst will automatically drop
them too.

Now that this new --skipfirst behavior is implemented as described
above, it should be relatively easy to adapt the code to implement
similar a option the makes emerge continue automatically after a
build failure (as suggested by you and in bug #12768).

Zac


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkhK51gACgkQ/ejvha5XGaP+zQCfRtjPWwaG/0/INhPdkX2Qg7O4
8J8An1d/iHN47gBknJ5cLCLozB49Ajjj
=A7Hj
-----END PGP SIGNATURE-----
--
gentoo-portage-dev@lists.gentoo.org mailing list
 

Thread Tools




All times are GMT. The time now is 12:21 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org