I'm trying to emerge latest ~x86 meld (v1.0) ebuild, these is the resulting dependency tree: emerge -pv meld These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N ] gnome-extra/nautilus-cd-burner-2.10.1 -debug +dvdr -hal 503 kB [ebuild N ] media-video/totem-1.0.3 -a52 -debug +dvd +flac -gnome -lirc +mad +mpeg +ogg -theora +vorbis -win32codecs +xine +xv 1,408 kB [ebuild N ] x11-libs/gtksourceview-1.2.0 -debug -doc 862 kB [ebuild N ] gnome-base/libgtop-2.10.1 -debug 733 kB [ebuild N ] dev-python/numeric-23.7 708 kB [ebuild U ] dev-python/pygtk-2.6.1 [2.4.1] -doc -gnome* +opengl 712 kB [ebuild U ] dev-python/pyorbit-2.0.1 [2.0.0] -debug 237 kB [ebuild U ] dev-python/gnome-python-2.10.0 [2.0.0-r1] -debug -doc -gtkhtml 351 kB [ebuild N ] dev-python/gnome-python-extras-2.10.2 -debug -doc -firefox -mozilla 342 kB [ebuild U ] dev-util/meld-1.0.0 [0.9.4.1-r1] -debug -doc 297 kB Is this dependency tree is required, can meld operate without totem for example? Reproducible: Always Steps to Reproduce:
These are the direct dependencies: <snip> DEPEND=">=dev-lang/python-2.2 >=gnome-base/libglade-2 >=gnome-base/libgnome-2 >=dev-python/gnome-python-1.99.15 >=dev-python/pygtk-1.99.15 >=dev-python/pyorbit-1.99.0 dev-python/gnome-python-extras " </snip> As for the rest, no-one can tell you where do they come from unless you post emerge --info w/ your USE flags.
emerge --info Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11.4 i686) ================================================================= System uname: 2.6.11.4 i686 Intel(R) Pentium(R) M processor 1.60GHz Gentoo Base System version 1.6.12 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Jun 12 2005, 13:52:53)] ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium-m -fprefetch-loop-arrays -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium-m -fprefetch-loop-arrays -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig buildpkg ccache distlocks prelink sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.hamakor.org.il/pub/mirrors/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://gentoo.zie.pg.gda.pl http://pandemonium.tiscali.de/pub/gentoo/" LDFLAGS=" -Wl,-O1 -Wl,--sort-common" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X alsa apm avi bash-completion bidi bitmap-fonts cdr cups curl dvd dvdr eds emboss encode fam flac foomaticdb fortran gd gdbm gif gphoto2 gpm gstreamer gtk gtk2 imagemagick imlib irda jpeg kde lcd libwww mad mmx mmx2 motif mp3 mpeg ncurses nls nptl ogg oggvorbis opengl pam pdflib pic png ppds radeon readline samba sdl slang spell sse sse2 ssl svga tcltk tcpd tiff truetype truetype-fonts type1-fonts unicode usb vorbis wxwindows xine xml xml2 xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LINGUAS
After a further research, it seems that gnome-python-extras has both gnome-extra/nautilus-cd-burner and media-video/totem in RDEPEND, so there seems no way around these deps via USE flags. Passing to gnome, no idea if all of these are really required.
the crux of this is gnome-python-extras. the configure.in has lazy bindings that do not have switches to turn on / off anything. Basically, if you have -totem in your useflags, the new program should not link against totem even if it *is* installed on your system. therefore, its not worth having a use flag for it since the configure.in doesn't support it. The answer to your question is yes, it can. if someone has time, the configure file will be patched. Please reopen if you have a patch for the configure file.
