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
This is related to 463976 in the sense the emerge doesn't remember *why* it is performing rebuilds.
(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 ?
*** Bug 654254 has been marked as a duplicate of this bug. ***
(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.
*** Bug 822102 has been marked as a duplicate of this bug. ***