Bug 629952

Summary:	portage --keep-going=y continues to proceed with subslot rebuilds even if the subslot change causing the rebuilds has failed
Product:	Gentoo Linux	Reporter:	Alexis Ballier <aballier>
Component:	Current packages	Assignee:	Portage team <dev-portage>
Status:	CONFIRMED ---
Severity:	normal	CC:	dan, esigra, franz.trischberger, mattst88, mgorny, nbowler, progenyx, sam, tsmksubc
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
See Also:	https://bugs.gentoo.org/show_bug.cgi?id=463976
Whiteboard:
Package list:		Runtime testing required:	---
Bug Depends on:
Bug Blocks:	373807

Description Alexis Ballier gentoo-dev

2017-09-05 11:57:39 UTC

Noticed with bug #629848:

- boost update causes a long list of subslot rebuilds here
- boost fails to build, so the subslot change does not happen
- I use keep-going=y and portage continues to proceed with the, now completely useless, := rebuilds caused by the boost upgrade

Comment 1 Zac Medico gentoo-dev

2017-09-05 20:58:59 UTC

This is related to 463976 in the sense the emerge doesn't remember *why* it is performing rebuilds.

Comment 2 Alexis Ballier gentoo-dev

2017-09-06 07:07:46 UTC

(In reply to Zac Medico from comment #1)
> This is related to 463976 in the sense the emerge doesn't remember *why* it
> is performing rebuilds.

For keep-going, isn't all the logic already in place ? In the sense that keep-going properly skips packages depending on one that has failed; rebuilds caused by subslots could simply be marked as depending on the package having its subslot change and then those would be skipped ?

Comment 3 Arfrever Frehtes Taifersar Arahesis 2018-04-29 00:36:11 UTC

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

Comment 4 Zac Medico gentoo-dev

2020-09-16 17:33:11 UTC

(In reply to Alexis Ballier from comment #2)
> (In reply to Zac Medico from comment #1)
> > This is related to 463976 in the sense the emerge doesn't remember *why* it
> > is performing rebuilds.
> 
> For keep-going, isn't all the logic already in place ? In the sense that
> keep-going properly skips packages depending on one that has failed;
> rebuilds caused by subslots could simply be marked as depending on the
> package having its subslot change and then those would be skipped ?

It currently reconstructs the merge list and dependency graph from the (incomplete) information available in /var/cache/edb/mtimedb (same as --resume). So, the reason for any given rebuild that existed in the original merge list is not available. Well have to come up with some way to propagate that information to the new dependency calculation.

Comment 5 Sam James archtester

2022-03-05 07:37:01 UTC

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