Just to give you a flavour of how sensitive visualizing RPM dependencies is to the precise method we use, compare two graphs for the kernel RPM.
The first is the one shown previously:
The second changes the order in which we traverse the dependency graph from depth-first to breadth-first:
initscripts (in green in the lower graph, buried near the bottom in the upper one), is both a direct dependency of kernel, and a very indirect dependency. In the lower, breadth-first, traversal we get to the direct dependency initscripts first, and so it is displayed immediately beneath kernel. Whereas in the upper graph we hit it as an indirect dependency of mkinitrd.
Both are true representations of the dependencies of kernel. It is true in some sense in the upper graph that mkinitrd is a “big” dependency, because it really does pull in all that data. It’s also true looking at the lower graph that mkinitrd is “small(er)”, because kernel directly pulls in packages like initscripts, and mkinitrd gets those “for free”.
Both are equally true but very different representations of the dependency graph.
Richard WM Jones 
Pingback: RPM dependency size viewer now available « Richard WM Jones
First, I don’t know what tool you are using to create these graphs. If it is self-written, or you are familiar enough to modify it, I have a minor suggestion.
It appears you are shading in the left portion of the bar to represent the size of the actual package (excluding dependencies). I believe right-aligning the dependencies underneath, so that they fall under the portion of the bar that represents dependencies, may improve the visual communication of this concept.
If I am being unclear, I could create a mock-up.
Jeff, thanks for commenting.
I think I see what you mean, and it’s a good idea. As I’m out of time on this package now, I’ll add it to an ideas/to-do list ..