I've already emerged xorg-x11 and now I'm attempting to emerge "gnome" and every time I do I get several circular reference errors, as shown by the logfile I've attached. Reproducible: Always Steps to Reproduce: 1. sudo emerge gnome 2. ...? 3. Profit! Actual Results: Three screenfuls of errors about circular references (see attached log) below the usual output of dependencies. Expected Results: the first package in the dependency list for "emerge gnome" should have begun downloading and then compiling. I'm doing this on a PowerBook G4 15" 1.67GHz (not the dual-layer SuperDrive model) with 1GB of RAM, a 120GB hard drive. The kernel is 2.6.14-gentoo-r3, filesystem is ReiserFS. sshd, pbbuttonsd, vixie-cron, syslog-ng, dhcpcd, and pccardd are all running in the background. Terminal is zsh but the problem also occurs in bash. Here's 'emerge --info': Portage 2.1.4.4 (default/linux/powerpc/ppc32/2008.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24-gentoo-r3 ppc) ================================================================= System uname: 2.6.24-gentoo-r3 ppc 7447A, altivec supported Timestamp of tree: Sun, 18 May 2008 06:45:03 +0000 app-shells/bash: 3.2_p17-r1 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.61-r1 sys-devel/automake: 1.6.3, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="ppc" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-O2 -mcpu=powerpc -mtune=powerpc -fno-strict-aliasing -pipe" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -mcpu=powerpc -mtune=powerpc -fno-strict-aliasing -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.chem.wisc.edu/gentoo/ " MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="acl avahi berkdb bzip2 cdr cli cracklib crypt cups dbus dri emacs firefox flac fortran gdbm gnome gpm gtk hal iconv ieee1394 ipod ipv6 isdnlog midi mudflap ncurses nls nptl nptlonly openmp pam pcmcia pcre perl ppc pppd python readline reflection ruby samba session spl ssl tcl tcpd unicode xorg zlib" ALSA_CARDS="aoa aoa-fabric-layout aoa-onyx aoa-soundbus aoa-soundbus-i2s aoa-tas aoa-toonie powermac usb-audio via82xx" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="fbdev glint mach64 mga nv r128 radeon savage tdfx trident voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Created attachment 153505 [details] Output of 'emerge gnome' These are the errors I'm seeing when I attempt to emerge the GNOME package.
does the following help ? echo "net-dns/avahi -gtk" >> /etc/portage/package.use echo "net-print/cups -avahi" >> /etc/portage/package.use I think both of these loops are known though.
I have the same issue on x86 platform. :(
(In reply to comment #3) > I have the same issue on x86 platform. :( Have you tried what Gilles suggested in comment 2 ? Thanks
(In reply to comment #2) > does the following help ? > > echo "net-dns/avahi -gtk" >> /etc/portage/package.use > echo "net-print/cups -avahi" >> /etc/portage/package.use > > I think both of these loops are known though. > I've tried this and nothing improved. Thanks for the suggestion though :)
It works. Please excuse my inability to read.
We've had this issue for a while now, and I thought there was a bug report, but I can't find any. Making this one be it. Lets please please not have those mostly useless gtk+ tools built ever at all, or have them be split out into a different package (that avahi package can PDEPEND conditionally if insisted to break the circular dep loop). Reassigning to avahi maintainer - this is the place where the chain can be broken cleanly.
I meant avahi provided tools that use gtk+. Ok, maybe not all avahi tarball provided gtk+ tools are useless, but they do need to be in a different package to get out of this chain. I guess I gnome@ can try helping in achieving that if necessary. This is making a clean system install with avahi added on from the start (as it's a cool thing to have for laptops and such) not possible cleanly, requiring temporarily not building avahi gtk+ using tools and then later rebuilding with them, once gtk+ is done.
I had the same problem when installing gnome after a newly installation with 2008.0.beta2. After using the method of comment #2, all the circular dependencies are gone. however, this is only a workaround of this problem. Are there any methods that can sovle the dependency problem?
(In reply to comment #9) > I had the same problem when installing gnome after a newly installation with > 2008.0.beta2. > After using the method of comment #2, all the circular dependencies are gone. > however, this is only a workaround of this problem. > Are there any methods that can sovle the dependency problem? > I got the same problem a few days ago installing 2008.0 final release
Still an issue today on i686, but comment #2 works!
Is this Bug still an issue?? Is there a known fix or is the workaround still the only way around it?? I have this issue on a newly created system with x86_64 arch.
I don't know about avahi, but cups and gtk+ have a circular dep. It's not one we can resolve easily.
No biggie was just curious. The comments from #2 also worked for me. Thanks for the fast reply :)
*** Bug 263755 has been marked as a duplicate of this bug. ***
*** Bug 280702 has been marked as a duplicate of this bug. ***
*** Bug 297308 has been marked as a duplicate of this bug. ***
I think correct solution here will be teach portage to solve such issues automagically. I guess some hints inside either gtk+ or cups are required to either first build gtk+[-cups] then cups[gtk] then gtk+[cups] or cups[-gtk] then gtk[cups] then cups[gtk]. I don't have proposal at the moment, but probably portage team already have idea on this issue. Guys was this reported anywhere? Do we need to solve bug 1343 for this?
(In reply to comment #18) > Do we need to solve bug 1343 for this? We already have some backtracking support that handles some of those cases of bug 1343, but for solving circular dependencies the backtracking a lot different from most other backtracking cases. I've posted an explanation of a way to handle it on bug 175808, comment 41. We won't necessarily need to add any more information in the dependencies since the resolver can simply disable flags until it finds a solution.
also, note that most of the time, a simple split of one package in the chain solves the dependency cleanly. Gnome team recently had to do it with libsoup and libsoup-gnome. I think in this case, avahi could be split into avahi (the libs) and avahi-utils or avahi-gtk-utils which the stuff that relies on gtk+. Hardest part is to convince upstream to make their package able to support build with already installed lib.
Sabayon already splitted avahi, we should probably do the same: http://gitweb.sabayon.org/?p=overlay.git;a=commit;h=3007040522391654bc46aaac7ec22e378d5e5412
FYI: created a ticket requesting avahi and avahi-ui to be split: https://bugs.gentoo.org/show_bug.cgi?id=399369
This circular dependency may now be broken in addressing bug #399369. It is possible to have USE="python" without pulling in gtk if all you want is the python bindings. There the only dependencies that are pulled in are dbus and gdbm not gtk. To be clear, I have not split avahi, just slimmed down the dependencies. Is there any easy way to test if this issue is solved?
Reviewing deps looks like people having "gtk zeroconf cups" in their make.conf will still get the circular dep problem :|
The current Sabayon ebuilds to handle this issue: https://github.com/Sabayon/sabayon-distro/tree/master/net-dns/
(In reply to Pacho Ramos from comment #25) > The current Sabayon ebuilds to handle this issue: > https://github.com/Sabayon/sabayon-distro/tree/master/net-dns/ I'm not going to split this package the way they do in sabayon. That's the wrong approach and we're not going to do that for every circular dep we hit, and there are a lot in dev-ruby and dev-python when USE=doc is set. The current workaround is to do a two tier emerge: 1) USE="zeroconf cups avahi" emerge avahi 2) USE=""zeroconf cups avahi gtk" emerge avahi The correct approach is difficult but nonetheless correct, and would involve portage recognizing the circular dependency, dropping one of the flags, and doing the two tier build automatically. Finally, the original circular dep was more annoying than what we currently have. Originally just emerge gnome would hit it and then comment 2 would help. Currenlty emerge gnome is fine and you need all four of those flags to hit it.
I haven't seen this issue in years.
Why was this closed as resolved? Im still affected by this: * Error: circular dependencies: (net-dns/avahi-0.7-r2:0/0::gentoo, ebuild scheduled for merge) depends on (x11-libs/gtk+-2.24.32-r1:2/2::gentoo, ebuild scheduled for merge) (buildtime) (net-print/cups-2.2.13:0/0::gentoo, ebuild scheduled for merge) (buildtime_slot_op) (net-dns/avahi-0.7-r2:0/0::gentoo, ebuild scheduled for merge) (buildtime) It might be possible to break this cycle by applying any of the following changes: - net-print/cups-2.2.13 (Change USE: -zeroconf) - net-dns/avahi-0.7-r2 (Change USE: -gtk) - x11-libs/gtk+-2.24.32-r1 (Change USE: -cups)
(In reply to Xeha from comment #28) > Why was this closed as resolved? > > Im still affected by this: > > * Error: circular dependencies: > > (net-dns/avahi-0.7-r2:0/0::gentoo, ebuild scheduled for merge) depends on > (x11-libs/gtk+-2.24.32-r1:2/2::gentoo, ebuild scheduled for merge) > (buildtime) > (net-print/cups-2.2.13:0/0::gentoo, ebuild scheduled for merge) > (buildtime_slot_op) > (net-dns/avahi-0.7-r2:0/0::gentoo, ebuild scheduled for merge) (buildtime) > > It might be possible to break this cycle > by applying any of the following changes: > - net-print/cups-2.2.13 (Change USE: -zeroconf) > - net-dns/avahi-0.7-r2 (Change USE: -gtk) > - x11-libs/gtk+-2.24.32-r1 (Change USE: -cups) You can get around it by temporarily adjusting USE flags as suggested there. We have bug 175808 about automating this for you in portage.
(In reply to Anthony Basile from comment #27) > I haven't seen this issue in years. Pretty obviously still a problem. We should simply drop gtk:2 support from avahi and be done with it. The USE="gtk gtk3" thing with avahi is bad anyway, so kill two birds with one stone by always disabling gtk:2 support and changing the meaning of IUSE=gtk to depend on gtk:3. I know you don't have a lot of time for Gentoo so I'll wait a bit and then probably make this change myself.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6114a43806e56434596bce6b0ad310c984d74920 commit 6114a43806e56434596bce6b0ad310c984d74920 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2020-04-02 18:26:27 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2020-04-02 19:02:06 +0000 net-dns/avahi: Shift USE=gtk to mean GTK+3 Bug: https://bugs.gentoo.org/222601 Signed-off-by: Matt Turner <mattst88@gentoo.org> net-dns/avahi/{avahi-0.8-r1.ebuild => avahi-0.8-r2.ebuild} | 12 ++++++------ net-dns/avahi/metadata.xml | 5 ++++- 2 files changed, 10 insertions(+), 7 deletions(-)
I think the circular dependency still exists, since gtk+:3 also has a dep on cups.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c409cdc5e5e455341cb30783fb6101349d98c6a6 commit c409cdc5e5e455341cb30783fb6101349d98c6a6 Author: Eli Schwartz <eschwartz93@gmail.com> AuthorDate: 2023-11-12 16:34:13 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-18 03:53:23 +0000 net-print/cups: drop cyclic dependency on cups-filters It is a PDEPEND which forces installing both, and makes building a modular cups-filters more challenging. Additionally, many "users" of cups may not actually want cups-filters at all. - A primary reason is because cups provides libcups, which other packages need as an RDEPEND in order to support USE=cups while not having any expectation of using a printing stack (at least, yet). - Even more fun, sometimes users have -bin packages where upstream has built the binaries against libcups on the assumption that users who want cups support will automatically get it and users who don't want cups support "just" need the debian libcups2 split binary package. This isn't really solvable without providing a minimal libcups-only experience. Rely instead on a metapackage for the full cups experience. Bug: https://bugs.gentoo.org/222601 Bug: https://bugs.gentoo.org/914586 Closes: https://bugs.gentoo.org/813507 Closes: https://github.com/gentoo/gentoo/pull/31784 Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> net-print/cups/cups-2.4.7-r2.ebuild | 313 ++++++++++++++++++++++++++++++++++++ 1 file changed, 313 insertions(+)
