I use Portage trunk (2.2.13_p27, 02ed485976fbf88a548c7b83978e23e3b50f41a2). # cat app-misc/A/A-1.ebuild EAPI="5" SLOT="1" KEYWORDS="*" DEPEND="|| ( app-misc/B app-misc/A:1 )" # cat app-misc/A/A-2.ebuild EAPI="5" SLOT="2" KEYWORDS="*" # cat app-misc/B/B-0.ebuild EAPI="5" SLOT="0" KEYWORDS="*" # emerge -optv app-misc/A:1 These are the packages that would be merged, in reverse order: Calculating dependencies... done! [nomerge ] app-misc/A-1:1::local [ebuild N ] app-misc/B-0::local 0 KiB Total: 1 package (1 new), Size of downloads: 0 KiB # emerge -1 app-misc/A:2 ... # emerge -optv app-misc/A:1 These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild NS ] app-misc/A-1:1::local [2:2::local] 0 KiB [ebuild N ] app-misc/B-0::local 0 KiB Total: 2 packages (1 new, 1 in new slot), Size of downloads: 0 KiB
I have a unit test based on comment #0 that reproduces this bug: https://github.com/zmedico/portage/tree/bug_524916
Created attachment 387600 [details, diff] dep_zapdeps: handle circular deps with --onlydeps This fixes a case with --onlydeps were dep_zapdeps would pull in an avoidable direct circular dependency on an onlydeps node. The logic changes only apply to --onlydeps, so there's no chance of regressions for cases when --onlydeps is not enabled.
This is in git now: https://github.com/gentoo/portage/commit/f883c84b36902afb3aecdd05c96ce6e6cd2394a6
Fixed in Portage 2.2.15.