circular dependencies

[zirkelad]

Whenever I try to emerge something after a recent emerge --sync I get the following:

Code: Select all

dori / # emerge -p net-analyzer/net-snmp    

These are the packages that would be merged, in order:

Calculating dependencies... done!
!!! Error: circular dependencies:

('ebuild', '/', 'net-print/foomatic-filters-ppds-20060720', 'merge') depends on
   ('ebuild', '/', 'net-print/foomatic-filters-3.0.20060720', 'merge') (medium)
   ('ebuild', '/', 'net-print/cups-1.2.6', 'merge') (soft)
('ebuild', '/', 'app-text/ghostscript-gpl-8.54', 'merge') depends on
   ('ebuild', '/', 'net-print/cups-1.2.6', 'merge') (hard)
('ebuild', '/', 'net-libs/gnutls-1.4.4-r1', 'merge') depends on
   ('ebuild', '/', 'dev-libs/lzo-2.02-r1', 'merge') (hard)
('ebuild', '/', 'dev-libs/lzo-2.02-r1', 'merge') depends on
   ('ebuild', '/', 'dev-lang/nasm-0.98.39-r3', 'merge') (hard)
('ebuild', '/', 'app-doc/doxygen-1.4.7', 'merge') depends on
   ('ebuild', '/', 'app-text/ghostscript-gpl-8.54', 'merge') (hard)
   ('ebuild', '/', 'virtual/ghostscript-0', 'merge') (hard)
('ebuild', '/', 'net-analyzer/net-snmp-5.4', 'merge') depends on
   ('ebuild', '/', 'app-doc/doxygen-1.4.7', 'merge') (hard)
('ebuild', '/', 'net-print/foomatic-filters-3.0.20060720', 'merge') depends on
   ('ebuild', '/', 'app-text/ghostscript-gpl-8.54', 'merge') (hard)
   ('ebuild', '/', 'net-print/cups-1.2.6', 'merge') (hard)
   ('ebuild', '/', 'virtual/ghostscript-0', 'merge') (hard)
('ebuild', '/', 'dev-lang/nasm-0.98.39-r3', 'merge') depends on
   ('ebuild', '/', 'app-text/ghostscript-gpl-8.54', 'merge') (hard)
   ('ebuild', '/', 'virtual/ghostscript-0', 'merge') (hard)
('ebuild', '/', 'net-print/cups-1.2.6', 'merge') depends on
   ('ebuild', '/', 'net-libs/gnutls-1.4.4-r1', 'merge') (hard)
('ebuild', '/', 'virtual/ghostscript-0', 'merge') depends on
   ('ebuild', '/', 'app-text/ghostscript-gpl-8.54', 'merge') (medium)
   ('ebuild', '/', 'net-print/cups-1.2.6', 'merge') (soft)

Any ideas?

stickied at genone's request - mark_alec
Unstuck as this has been addressed in more recent versions of portage. -- desultory

[jmbsvicetto]

Hi.

Please post your emerge --info. Have you done anything different / special with emerge?

[n506]

same problem since last --sync (few hours ago). there was no problem with previous sync in december.

Code: Select all

Calculating dependencies... done!
!!! Error: circular dependencies:

('ebuild', '/', 'app-text/djvu-3.5.17', 'merge') depends on
   ('ebuild', '/', 'x11-libs/qt-3.3.6-r4', 'merge') (hard)
('ebuild', '/', 'x11-libs/qt-3.3.6-r4', 'merge') depends on
   ('ebuild', '/', 'net-print/cups-1.2.6', 'merge') (hard)
('ebuild', '/', 'app-text/ghostscript-gpl-8.54', 'merge') depends on
   ('ebuild', '/', 'app-text/djvu-3.5.17', 'merge') (hard)
   ('ebuild', '/', 'net-print/cups-1.2.6', 'merge') (hard)
('ebuild', '/', 'net-libs/gnutls-1.4.4-r1', 'merge') depends on
   ('ebuild', '/', 'dev-libs/lzo-2.02-r1', 'merge') (hard)
('ebuild', '/', 'dev-lang/nasm-0.98.39-r3', 'merge') depends on
   ('ebuild', '/', 'app-text/ghostscript-gpl-8.54', 'merge') (hard)
   ('ebuild', '/', 'virtual/ghostscript-0', 'merge') (hard)
('ebuild', '/', 'dev-libs/lzo-2.02-r1', 'merge') depends on
   ('ebuild', '/', 'dev-lang/nasm-0.98.39-r3', 'merge') (hard)
('ebuild', '/', 'net-print/cups-1.2.6', 'merge') depends on
   ('ebuild', '/', 'net-libs/gnutls-1.4.4-r1', 'merge') (hard)
('ebuild', '/', 'virtual/ghostscript-0', 'merge') depends on
   ('ebuild', '/', 'app-text/ghostscript-gpl-8.54', 'merge') (medium)
   ('ebuild', '/', 'net-print/cups-1.2.6', 'merge') (soft)

my problem is solved with removing "cups" from USE flags. fortunately i don't really need it.

[KShots]

I'm having similar problems. I'm trying a stage-3 install from a minimal disc, and I'm having a hell of a time hacking my way through this.

The best thing I've found so far is to do an USE="-*" emerge --emptytree world, then re-emerge the world with your normal USE flags afterwards. Somebody really, really broke portage bad.

Note that this will take about forever and a half to complete, so you may be better off waiting until a portage fix comes around (unless you're starting from scratch like me, that is).

[Genone]

The best thing I've found so far is to do an USE="-*" emerge --emptytree world

Be aware that you may run into very nasty problems when you do that.

[KShots]

I don't seem to have much of a choice. I'm not quite doing that, exactly, but I'm doing something pretty close to it. Starting from scratch on a stage-3, nothing will emerge unless I add the "USE=-*" environment variable. It seems I can re-emerge after something has completed to get the proper USE flags in, but until then I have to emerge everything without USE flags. I've already have to re-compile kdelibs 3 times due to Qt at first being stripped of its USE flags, then kdelibs being able to compile with USE flags but finding Qt didn't have OpenGL, then re-compiling Qt and finding that kdenetwork couldn't compile while kdelibs had different flags than Qt... you get the picture.

I'm working through it because it's that or I don't have a working system. If you already have a working system, wait until someone fixes portage.

[madisonicus]

Have you had a look at http://www.gentoo.org/proj/en/portage/d ... ortage.xml? Or just waited a while and resyncd?

An emptytree emerge with no USE flags sounds like a lot of effort, all of which will have to be undone when you want USE flags again. Moreover, the problem appears to be in your portage, not in your system, right? So, why re-emerge the system when portage is the problem?

[Genone]

Have you had a look at http://www.gentoo.org/proj/en/portage/d ... ortage.xml?

Please don't recommend that as a catchall solution, it has a very specific purpose (as a replacement for `emerge portage` if emerge doesn't work at all) and should only be used for that.

[madisonicus]

Have you had a look at http://www.gentoo.org/proj/en/portage/d ... ortage.xml?

Please don't recommend that as a catchall solution, it has a very specific purpose (as a replacement for `emerge portage` if emerge doesn't work at all) and should only be used for that.

Sure thing. Just presenting options.... and that one was a bad one.

[KShots]

An emptytree emerge with no USE flags sounds like a lot of effort, all of which will have to be undone when you want USE flags again.

You're right there. I'm wondering if my system can compile all this (since it's essentially starting from scratch) faster than the portage devs can fix the problem. That's the only reason I'm willing to attempt to tackle it this way.

Moreover, the problem appears to be in your portage, not in your system, right? So, why re-emerge the system when portage is the problem?

Portage is part of the problem, but the main problem is circular dependencies in portage. If I can bypass that by having something in place to emerge everything else, I can work around the circular dependencies and have a working system, and use it while it re-builds everything with the proper USE flags. In other words, I'm impatient while I'm building my base system. Instead of waiting like I recommend others do, I'm letting my system work its arse off to work around the problem.

[zmedico]

With versions of portage <2.1.2 there was never really any guarantee that a package's dependencies would actually be installed before the package itself. That issue is fixed in portage-2.1.2 ([bug=147766]bug 147766[/bug]) so that correct merge order is always guaranteed and circular dependencies will be reported if they exist. This circular dependency detection prevents random build errors that could otherwise be caused by unsatisfied dependencies (see [bug=147127]bug 147127[/bug], for example).

In portage-2.1.2-r9, the circular dependency output is often excessively verbose, making it difficult to discern dependency cycles. See [bug=166564]bug 166564[/bug] for a patch which eliminates excess noise. This patch will be included in portage-2.1.2-r10.

Generally, dependency cycles can be broken by disabling USE flags. For example, in order to break the following cycle:

app-text/ghostscript-gpl-8.54 -> net-print/cups-1.2.6 -> net-libs/gnutls-1.4.4-r1 -> dev-libs/lzo-2.02-r1 -> dev-lang/nasm-0.98.39-r3 -> app-text/ghostscript-gpl-8.54

Temporarily add the following to /etc/portage/package.use:

Code: Select all

=dev-lang/nasm-0.98.39-r3 -doc

This will break that dependency cycle so that those packages can be built and installed. After those package are installed, remove the above package.use setting and remerge nasm with the doc flag enabled. Future versions of portage will be able to do these steps automatically, but it will require the dependency resolver to be rewritten.

[KShots]

At any rate, I believe I've managed to get around my circular dependency problem - now I have a clear path to compiling KDE with all my USE flags enabled. I look forward to this dependency resolver you mention .

[jettjunker]

Generally, dependency cycles can be broken by disabling USE flags. For example, in order to break the following cycle:

How am I supposed to figure those out? I can't even emerge -pv to figure out which use flags are used and go at it with trial and error...

Blech, this change really should not have been made until AFTER the dependency resolver was included... Any idea how long we are looking at having to deal with this?

[Brainfart]

I got through it with guess and check. -doc was a big one, and then emerging cups was a little process toggling the cups and dbus USE flags, and I had to do a USE="-java" emerge sun-jdk (that one cracked me up), but that's about all I can remember. mostly USE="-what_your_package_is_for" emerge yourpackage && emerge yourpackage.

[KShots]

Don't forget to emerge -N world afterwards, or you may have dependencies with improper USE flags.

[hielvc]

The easist way is to

Code: Select all

emerge --oneshot --nodeps cups ghostscript

Then re-emerge them with

Code: Select all

emerge --oneshot cups ghostscript 

[ffaerton]

This will break that dependency cycle so that those packages can be built and installed. After those package are installed, remove the above package.use setting and remerge nasm with the doc flag enabled. Future versions of portage will be able to do these steps automatically, but it will require the dependency resolver to be rewritten.

Thanks, that piece of understanding really helped <insert emoticon for a thumbs up/>

[fumoffu]

I'm currently setting up a fresh install on my new box and the circular dependencies keep me from installing kdebase. Will I have to wait for the developers to fix portage? I tried disabling some useflags, but no success. The --oneshot --nodeps option did not work either.

[zmedico]

I'm currently setting up a fresh install on my new box and the circular dependencies keep me from installing kdebase. Will I have to wait for the developers to fix portage? I tried disabling some useflags, but no success. The --oneshot --nodeps option did not work either.

If you apply the patch from [bug=166564]bug 166564[/bug] then it should be easier to discern dependency cycles. I'll be releasing portage-2.1.2-r10 with that patch today.

[zmedico]

The easist way is to

Code: Select all

emerge --oneshot --nodeps cups ghostscript

--nodeps is effectively equivalent to what used to happen before emerge was able to detect circular dependencies. There's no guarantee that a package will build like that without it's dependencies installed. In fact, an ebuild *should* fail to build if one or more dependencies aren't installed as required by current USE settings. If the ebuild succeeds anyway, then it's really a QA problem that should be fixed. --nodeps is a hack. The proper solution is to temporarily disable USE flags in order to break dependency cycles.

[sonicbhoc]

same problem since last --sync (few hours ago). there was no problem with previous sync in december.

Code: Select all

Calculating dependencies... done!
!!! Error: circular dependencies:

('ebuild', '/', 'app-text/djvu-3.5.17', 'merge') depends on
   ('ebuild', '/', 'x11-libs/qt-3.3.6-r4', 'merge') (hard)
('ebuild', '/', 'x11-libs/qt-3.3.6-r4', 'merge') depends on
   ('ebuild', '/', 'net-print/cups-1.2.6', 'merge') (hard)
('ebuild', '/', 'app-text/ghostscript-gpl-8.54', 'merge') depends on
   ('ebuild', '/', 'app-text/djvu-3.5.17', 'merge') (hard)
   ('ebuild', '/', 'net-print/cups-1.2.6', 'merge') (hard)
('ebuild', '/', 'net-libs/gnutls-1.4.4-r1', 'merge') depends on
   ('ebuild', '/', 'dev-libs/lzo-2.02-r1', 'merge') (hard)
('ebuild', '/', 'dev-lang/nasm-0.98.39-r3', 'merge') depends on
   ('ebuild', '/', 'app-text/ghostscript-gpl-8.54', 'merge') (hard)
   ('ebuild', '/', 'virtual/ghostscript-0', 'merge') (hard)
('ebuild', '/', 'dev-libs/lzo-2.02-r1', 'merge') depends on
   ('ebuild', '/', 'dev-lang/nasm-0.98.39-r3', 'merge') (hard)
('ebuild', '/', 'net-print/cups-1.2.6', 'merge') depends on
   ('ebuild', '/', 'net-libs/gnutls-1.4.4-r1', 'merge') (hard)
('ebuild', '/', 'virtual/ghostscript-0', 'merge') depends on
   ('ebuild', '/', 'app-text/ghostscript-gpl-8.54', 'merge') (medium)
   ('ebuild', '/', 'net-print/cups-1.2.6', 'merge') (soft)

my problem is solved with removing "cups" from USE flags. fortunately i don't really need it.

Well, when I have this problem, I remove the use flag causing the circular dep problem (in this case, cups), emerge the program, re-add the use flag and emerge -uNav the package.

[thm]

To begin with, these circular dependencies are probably real (at least in some cases) and not the result of someone breaking portage. It's also a good thing that the new portage versions detect these problems and that ebuild authors are recording the depencies diligently. This is definitely part of the solution and not the source of the problem. However, I am sceptical that it will be possible to resolve circular dependencies automatically any time soon. Why ?

Obviously, the depency graph is a function of the USE flags. My own moderately complex gentoo system currently has 74 USE flags (including some lingua-flags) set in make.conf. If only a third of those is relevant for a larger upgrade (larger ones, of course, are more prone to circular dependencies), then unless one can make some systematic assumptions about USE flags an automatic resolver would need to choose one out of (2^25)-1 possible dependency graphs just to test the feasibility of the first step (i.e., something like USE="+abc -xyz" emerge...") of a path towards the final goal (which is having everything compiled with the USE flags originally selected by the user - although there may be combinations that turn out to be impossible)

If one intermediate step is enough and the second step gets us to the desired result, the resolver wins and we're happy. If not, we need to look at another (2^25)-2 dependency graphs for the second intermediate step, and so on... Of course, one would choose slightly more intelligent search strategies such as favoring small numbers of USE flag overrides. Still, it's a formidable search space... not unlike chess...

On the other hand, it's probably fairly easy to identify the prime culprits based on knowledge about their meaning: USE flags in low level packages (such as doc in gettext) that incur dependencies on high level utilities, e.g. related to documentation processing or printing. I am experiencing problems with "doc" and I'm not surprised that people are complaining about "cups". I think that a short list of such USE flags to check along with some improved reporting by the current resolver will be more successful than an attempt at full automation.

[thm]

The easist way is to

Code: Select all

emerge --oneshot --nodeps cups ghostscript

.... In fact, an ebuild *should* fail to build if one or more dependencies aren't installed as required by current USE settings. If the ebuild succeeds anyway, then it's really a QA problem that should be fixed.

I don't quite agree. The ability of some configure scripts to cope with poor environments is remarkable. The ebuild could run smoothly, but some features of the installed software might be missing or broken.

--nodeps is a hack. ...

Indeed, and a bad one at that.

[thm]

I'm currently setting up a fresh install on my new box and the circular dependencies keep me from installing kdebase. Will I have to wait for the developers to fix portage? I tried disabling some useflags, but no success. The --oneshot --nodeps option did not work either.

You didn't detail what you tried or which USE flags are still set. Try

Code: Select all

USE="-*" emerge --pretend --newuse --deep world

If that doesn't work, the only suggestion I have is to start from scratch.
If it does work, try eliminating fewer USE flags. "doc" certainly is a likely culprit.
Once you know the USE flags you have to leave out, re-run the command without the --pretend.
If that works, emerge again with all your original USE flags and the --newuse and --deep options.

[zmedico]

If one intermediate step is enough and the second step gets us to the desired result, the resolver wins and we're happy. If not, we need to look at another (2^25)-2 dependency graphs for the second intermediate step, and so on... Of course, one would choose slightly more intelligent search strategies such as favoring small numbers of USE flag overrides. Still, it's a formidable search space... not unlike chess...

It certainly is formidable, but my hope is that we'll be able to use various heuristics to reduce the search space. For example, we know that certain flags such as "doc" are common culprits, so we can have a list of preferred flags to disable in attempts to break cycles. We can also use the reference count of a given node to measure whether it is a good choice when looking for a candidate with flags to disable. For example, the nasm package probably has a higher than average number of other packages referencing it, so that might indicate that it's a good candidate.

On the other hand, it's probably fairly easy to identify the prime culprits based on knowledge about their meaning: USE flags in low level packages (such as doc in gettext) that incur dependencies on high level utilities, e.g. related to documentation processing or printing. I am experiencing problems with "doc" and I'm not surprised that people are complaining about "cups". I think that a short list of such USE flags to check along with some improved reporting by the current resolver will be more successful than an attempt at full automation.

Hopefully the output produced by portage-2.1.2-r10 is more user friendly than previous versions. Here's an example:

Code: Select all

$ emerge nasm

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    ] net-libs/gnutls-1.6.1  USE="doc nls zlib"
[ebuild  N    ]  dev-libs/lzo-2.02-r1  USE="-examples"
[ebuild  N    ]   dev-lang/nasm-0.98.39-r3  USE="doc -build"
[ebuild  N    ]    virtual/ghostscript-0
[ebuild  N    ]     app-text/ghostscript-gpl-8.54  USE="cups -X -cjk -djvu -emacs -gtk -jpeg2k"
[ebuild  N    ]      net-print/cups-1.2.7  USE="nls pam ppds ssl -X -dbus -jpeg -php -png -samba -slp -tiff"
!!! Error: circular dependencies:

('ebuild', '/', 'app-text/ghostscript-gpl-8.54', 'merge') depends on
   ('ebuild', '/', 'net-print/cups-1.2.7', 'merge') (hard)
('ebuild', '/', 'net-libs/gnutls-1.6.1', 'merge') depends on
   ('ebuild', '/', 'dev-libs/lzo-2.02-r1', 'merge') (hard)
('ebuild', '/', 'net-print/cups-1.2.7', 'merge') depends on
   ('ebuild', '/', 'net-libs/gnutls-1.6.1', 'merge') (hard)
('ebuild', '/', 'dev-libs/lzo-2.02-r1', 'merge') depends on
   ('ebuild', '/', 'dev-lang/nasm-0.98.39-r3', 'merge') (hard)
('ebuild', '/', 'dev-lang/nasm-0.98.39-r3', 'merge') depends on
   ('ebuild', '/', 'app-text/ghostscript-gpl-8.54', 'merge') (hard)
   ('ebuild', '/', 'virtual/ghostscript-0', 'merge') (hard)
('ebuild', '/', 'virtual/ghostscript-0', 'merge') depends on
   ('ebuild', '/', 'app-text/ghostscript-gpl-8.54', 'merge') (medium)
   ('ebuild', '/', 'net-print/cups-1.2.7', 'merge') (soft)

!!! Note that circular dependencies can often be avoided by temporarily
!!! disabling USE flags that trigger optional dependencies.

Note the --tree style output (with indentation to indicate dependency relationships) and the display of USE flag settings (in order to help the user decide which flags to disable).