circular dependencies

[zirkelad]

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

[jmbsvicetto]

Hi.

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

Your twisted, but hopefully friendly daemon.
AMD64 / x86 / Sparc Gentoo
Help answer || emwrap.sh

[n506]

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

[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).
_________________
Life without passion is death in disguise

[Genone]

[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.
_________________
Life without passion is death in disguise

[madisonicus]

Have you had a look at http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.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?
_________________
Please add [SOLVED] to your message title if you feel that your question has been answered.
------
Intel Q9300 Core2 Quad * Gigabyte GA-EP35C-DS3R
Samsung x360
AMD64 x2 4200+ * TF7050-M2 * HTPC
ZOTAC ION A-U Mini-ITX * HTPC

[Genone]

[madisonicus]

[KShots]

[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) 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, 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 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:

[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 .
_________________
Life without passion is death in disguise

[jettjunker]

[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.
_________________
Life without passion is death in disguise

[hielvc]

The easist way is to

[ffaerton]

[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.
_________________
"People said I should accept the world. Bullshit! I don't accept the world!"
- Richard Stallman

http://www.lastfm.de/user/penguin-guy

[zmedico]

[zmedico]

[sonicbhoc]

[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.
_________________
Thomas

[thm]

[thm]

[zmedico]