FWIR, Portage attempts to silently ignore pure RDEP-RDEP circular dependencies, and proceed with undefined merge order. This is a very bad idea since it means that developers can't reliably rely on RDEP being installed, as it could by bypasses by a deep indirect dependency change they are completely unaware of, and which is hard to notice afterwards. Instead, it'd be better to fail properly and have developers explicitly use PDEPEND. Most notably, it makes the developers aware of the problem and lets them explicitly choose which of the dependencies is less important.
The depgraph._serialize_tasks method has a "runtime cycle digraph" debug message that we can turn into a QA Notice, then we can make it fatal after the notice has been in a stable release for some time.
Oh nice, I didn't know about that. That would be even better, I guess. Does it trigger on installed systems as well (i.e. for potential circulars), or only when the circular dep actually is bypassed?
(In reply to Michał Górny from comment #2) > Does it trigger on installed systems as well (i.e. for potential circulars), or > only when the circular dep actually is bypassed? It only triggers when a circular dep is actually bypassed. There is a drop_satisfied flag that is set to True as a last resort, when necessary to solve circular build-time deps, but runtime cycles can be selected for merge when the drop_satisfied is False. If circular RDEPEND are conditional on USE flags, then they might be "valid" in the sense that they are solvable by building with one USE setting and then rebuilding with another USE setting. The depgraph._serialize_tasks code is not aware of whether a particular dependency can be avoided by changing the USE state, but pym/_emerge/resolver/circular_dependency.py has some code for analyzing this sort of thing and suggesting manual USE flag changes. We could use this to filter out "valid" circular runtime deps that are conditional.
(In reply to Zac Medico from comment #3) > (In reply to Michał Górny from comment #2) > > Does it trigger on installed systems as well (i.e. for potential circulars), or > > only when the circular dep actually is bypassed? > > It only triggers when a circular dep is actually bypassed. There is a > drop_satisfied flag that is set to True as a last resort, when necessary to > solve circular build-time deps, but runtime cycles can be selected for merge > when the drop_satisfied is False. Actually it also triggers on installed systems, because the drop_satisfied is still False when it selects a runtime cycle to merge.
