Comment 7 for bug 414027

This also affects more basic packages like gcalctool, acl, linux-image, binutils etc. In fact I can't find a single package where it actually pops up a rendered a graph within reasonable time. Our definitions of reasonable might be different though :-)

btw, I'm seeing this:

$ cat firefox.txt | g '\->' | wc -l
10471
$ cat firefox.txt | g shape | wc -l
2505

...and I wonder, is it realistic for graphviz to handle 2500 nodes with 10k edges?

I was thinking, if graphviz could provide some progress information during layout then dotty could show a UI progress bar with a cancel button. But, in reality the time dotty takes to render these graphs is so long that a progress bar doesn't really help a lot. Indeed, it makes me suspect that maybe we're dealing with a simpler bug that makes graphviz go into an infinite CPU spin loop?

If it's verified that the firefox dep graph (and indeed many other packages) is indeed too heavy for graphviz and this is not a graphviz bug, it would make sense to A) investigate if some other graph layout (other than "dot") can be used within graphviz to make it faster, or B) use some other graph library instead of using graphviz, or C) have apt-cache prune the graph when it gets too complicated (either by not showing all kinds of edges like conflicting/recommended etc) or by simply not showing all dependencies (i.e. maybe just first level or first+second level dependencies).