Summary: | sys-apps/portage: Please disable the circular RDEP bypass | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Michał Górny <mgorny> |
Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | berinaniesh, esigra, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=906809 https://github.com/pkgcore/pkgcheck/issues/400 https://github.com/pkgcore/pkgcheck/pull/603 https://bugs.gentoo.org/show_bug.cgi?id=921632 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 155723 |
Description
Michał Górny
2018-02-16 05:44:45 UTC
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. |