without this the depgraph is incorrect, in particular we had to run emerge -1eav @world to fix some problems with certain binaries, and with bison only being repaired after pam merge ... Reproducible: Always
Whilst you're at it ... ditto for dev-tcltk/expect
Sorry, expect is for gcc.
sys-libs/pam BDEPENDs on virtual/yacc, which RDEPENDs on sys-devel/bison, so I think the dependency is correct. Nevertheless, I can reproduce as follows. $ emerge -pe --ignore-default-opts sys-libs/pam | grep -E 'sys-libs/pam|sys-devel/bison|virtual/yacc' [ebuild R ] virtual/yacc-0 [ebuild R ] sys-libs/pam-1.5.1_p20210622-r1 [ebuild R ] sys-devel/bison-3.8.2 This is also the case with @system, reproduced similarly to above with the same output.
Yeah, I looked into this part of the code. It sees that there's a massive cyclic dependency graph (in my case 311 nodes). For such a graph it tries to progressively increase the "priority" (in other words, the strength of the dependency), and find leaf nodes on each step, where leaf nodes are ebuilds that have no non-ignored dependencies. First it starts by ignoring PDEPENDs, there's no leaf node. Then RDEPENDs, app-alternatives/yacc is part of this batch. This means that it has no dependencies that's of higher strength than RDEPEND. Then BDEPEND & DEPEND that are satisfied by currently installed packages. sys-libs/pam & sys-devel/bison are part of this batch. I'm not sure how one would fix this.
Guessing PDEPEND at least can be handled as if it's been passed like another package to merge fro the word go, ie, as a leave node that needs to be installed at some point during the merge process. This may at least eliminate one layer of backtracking from the onset. For loops that doesn't involve PDEPEND obviously this gets much more involved and at this point I suspect one will have to make certain assumptions, like "we have a working $CC" for example, so one would need to determine in some way what the packages are that can be assumed on --empty as "can be safely delayed"?
It's at least related to (if not going to be solved by) bug 754777.
