emerge --keep-going returns with exit state 0 on failure on portage-2.2_rc6 at least, if after the failing package more packages are successfully emerged. Another related problem with --keep-going (because it is also related with portage not keeping track about the package failures) is the following - not sure whether it should be considered as a bug or as intended behavior: I wanted to upgrade gwenhywfar (2.6.1->2.6.2) and aqbanking (2.3.2->2.3.3) with --keep-going; aqbanking depends on gwenhywfar. However, although gwenhywfar failed, aqbanking was emerged afterwards. This might be considered reasonable, because aqbanking will also run with the previous version of gwenhywfar. On the other hand, I would have considered it more reasonable that aqbanking does not compile, because its dependency failed - compiling it against a version which should be obsoleted in the same emerge command is usually never what you want.
(In reply to comment #0) > emerge --keep-going returns with exit state 0 on failure on portage-2.2_rc6 > at least, if after the failing package more packages are successfully emerged. This part is fixed in This is fixed in 2.2_rc35. (In reply to comment #0) > tOn the other hand, I would have considered > it more reasonable that aqbanking does not compile, because its dependency > failed - compiling it against a version which should be obsoleted in the > same emerge command is usually never what you want. Maybe we need a separate option for this because I imagine there might be a use for both behaviors. Also, this one is more important if there is an ABI change than if there isn't.
*** Bug 533706 has been marked as a duplicate of this bug. ***
The complexity is in tracking all of the rebuild reasons so that we can know when we've exhausted them all. On the opposite side of the spectrum, for emerge -e @world, we would go ahead and perform as many rebuilds as possible in spite of any failures.
For rebuilds related to sub-slot or ABI change, we can use the code related to bug 472104 as a metric.