Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 647824 - sys-apps/portage: Please disable the circular RDEP bypass
Summary: sys-apps/portage: Please disable the circular RDEP bypass
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Dependencies (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 155723
  Show dependency tree
 
Reported: 2018-02-16 05:44 UTC by Michał Górny
Modified: 2024-01-10 11:29 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-02-16 05:44:45 UTC
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.
Comment 1 Zac Medico gentoo-dev 2018-02-16 17:17:39 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.
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-02-16 19:41:59 UTC
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?
Comment 3 Zac Medico gentoo-dev 2018-02-17 20:10:38 UTC
(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.
Comment 4 Zac Medico gentoo-dev 2018-02-17 20:33:55 UTC
(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.
Comment 5 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-01-08 09:18:40 UTC
(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?
Comment 6 Zac Medico gentoo-dev 2024-01-08 18:12:33 UTC
(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.
Comment 7 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-01-10 11:29:27 UTC
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.