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.
(In reply to Zac Medico from comment #1) > 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. Would it be good enough to promote it to a QA notice only if it's not a cycle of length 1? Or are we still going to get find_smallest_cycle "FPs" then?
(In reply to Sam James from comment #5) > (In reply to Zac Medico from comment #1) > > 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. > > Would it be good enough to promote it to a QA notice only if it's not a > cycle of length 1? Or are we still going to get find_smallest_cycle "FPs" > then? It seems like that should work fine. Making this fatal does not seem feasible given without some additional metadata given the glibc RDEPEND "cycle" shown in attachment #875041 [details]. As noted in bug 921580 comment #13, sys-libs/glibc has an RDEPEND on media-libs/gd, but libgd.so.3 is really only used by glibc's /usr/bin/memusagestat which seems non-essential. Some additional metadata to represent this relationship could be useful within the context of a QA notice or fatal error.
Another interesting one is libpcre2. It is multilib and it depends on bzip2, readline, zlib only for the native ABI because it installs extra tools there. In an emergency, that's less important than keeping the library working - which grep depends on.