I believe the reason behind Bug 70036 is that emerge is showing the list of packages based on the compile sequence. However, what many users (including me) are looking for is a tree output based exclusively on DEPENDS/RDEPENDS or USE-based dependencies. An option to generate such a tree should be added to emerge. Otherwise it can be very frustrating trying to find out *why* a particular package is being included, because as-is, the tree does not show this relationship. For example, on a system that has no X or tk, I wanted to emerge rpm. Issuing "emerge --pretend --verbose --tree rpm" yielded: [ebuild N ] app-arch/rpm-4.2-r1 +doc +nls +python 9,513 kB [ebuild N ] dev-libs/elfutils-0.108 +nls 921 kB [ebuild NS ] sys-libs/db-3.2.9-r10 +doc -java 2,036 kB [ebuild NS ] sys-libs/db-1.85-r2 279 kB [ebuild N ] app-crypt/gnupg-1.4.1 -X +bzip2 -caps +curl -ecc -idea +ldap +nls +readline (-selinux) -smartcard +zlib 2,756 kB [ebuild N ] net-misc/curl-7.13.2 -ares -ipv6 +ldap +ssl 2,961 kB [ebuild N ] app-doc/doxygen-1.4.2 +doc -qt -tetex 2,790 kB [ebuild N ] app-text/ghostscript-7.07.1-r8 -X -cjk +cups -emacs -gtk 5,273 kB [ebuild N ] net-print/cups-1.1.23-r1 +nls +pam -samba (-slp) +ssl 8,501 kB [ebuild N ] media-libs/tiff-3.7.3 1,242 kB [ebuild N ] media-fonts/gnu-gs-fonts-std-8.11 3,664 kB [ebuild N ] x11-terms/xterm-204 -Xaw3d -toolbar -truetype -unicode 698 kB [ebuild N ] sys-apps/utempter-0.5.5.6 20 kB [ebuild N ] media-gfx/graphviz-1.10 +tcltk 3,278 kB [ebuild N ] dev-lang/tk-8.4.9 +threads 3,189 kB [ebuild N ] x11-base/xorg-x11-6.8.2-r4 (-3dfx) (-3dnow) -bitmap-fonts -cjk -debug -dlloader -dmx +doc -font-server -insecure-drivers -ipv6 -minimal (-mmx) +nls -nocxx -opengl +pam -sdk (-sse) -static -truetype-fonts -type1-fonts (-uclibc) -xprint -xv 45,110 kB [ebuild N ] x11-misc/ttmkfdir-3.0.9-r3 19 kB [ebuild N ] media-libs/fontconfig-2.2.3 732 kB [ebuild N ] media-libs/freetype-2.1.9-r1 -bindist +doc +zlib 1,183 kB [ebuild N ] media-libs/libpng-1.2.8 +doc 500 kB [ebuild N ] media-libs/jpeg-6b-r5 598 kB It is completely unclear from this listing that (with the +doc USE flag) doxygen depends on graphviz which due to the tcltk flag being set pulls in tk, which requires xorg which in turn requires xterm. Instead, xterm is at the root level of the tree with graphviz as a descendant and the tree output alone is not enough to figure out how simply wanting to install rpm leads to xterm being pulled in. The system is Gentoo 2005.1 with portage-2.0.51.22-r2 . There may be some other option name that should be used instead of --tree for this different type of tree listing. Reproducible: Always Steps to Reproduce: As an example: 1. Build a Gentoo 2005.1 system with USE flags including: +doc -X , and without any form of X installed 2. Perform "emerge -pvt rpm" 3. Observe that xterm is on the installation list without any hierarchy context that indicates what depends on xterm and why portage wants to install it Actual Results: Gives a tree of packages that will be installed based on some dependence information, but governed by the compilation sequence. Expected Results: A tree which shows what packages are going to be installed and why, based on USE flags and dependence information, without necessarily going strictly in compilation order. In the example cited above, xterm *should* be a child of xorg, and it should be clear that the doc USE flag is causing doxygen to be installed, which depends on graphviz, which due to the tcltk USE flag depends on tk which depends on xorg which depends on xterm. See also: http://bugs.gentoo.org/show_bug.cgi?id=70036
I have this working in one of the experimental branches. Dependencies are shown under (and only under) the packages that depend on them. Where a package is depended on by multiple packages, it is shown for each of the parents but its own dependencies are only listed under its first appearance. In this way all dependencies are visible and circular dependencies can be cross-referenced easily. Being in an experimental branch pretty much means it or a better version of it will make it to a release one day, so I'll mark this one as LATER.
*** Bug 155098 has been marked as a duplicate of this bug. ***
Does this need any more work?
I think it does because current portage (2.1.2_rc1-r5) still have the same problem. See also bug #155098.
Can anyone provide a current test-case? The given one doesn't apply anymore AFAICT
*** Bug 138249 has been marked as a duplicate of this bug. ***
The current --tree algorithm is fundamentally flawed in that it doesn't account for multiple parents.
*** Bug 118332 has been marked as a duplicate of this bug. ***
Zac, isn't this fixed by the new --tree display stuff?
Some issues have been fixed in the --tree output but it does still leave something to be desired, such as the ability to display conditional dependencies as mentioned in comment #0. I think that we should probably leave the --tree output the way that it is now and any major improvements should part of a new display format as suggested in bug #169047.
Considering this 50:50 fixed/wontfix based on comment #10.
