Bug 234101 – emerge --keep-going should account for failed upgrades (with possible sub-slot or ABI change)

• Product: Portage Development
• Status: CONFIRMED ---

[Description Martin Väth 2008-08-06 16:27:52 UTC]

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.

[Comment 1 Zac Medico 2009-08-07 16:31:50 UTC]

(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.

[Comment 2 Zac Medico 2014-12-28 23:35:30 UTC]

*** Bug 533706 has been marked as a duplicate of this bug. ***

[Comment 3 Zac Medico 2021-04-17 17:39:39 UTC]

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.

[Comment 4 Zac Medico 2021-04-17 17:43:39 UTC]

For rebuilds related to sub-slot or ABI change, we can use the code related to bug 472104 as a metric.