

A nice picture of (dependency) hell - ESCdc
http://disfunksioneel.blogspot.com/2011/04/linux-software-dependencies.html

======
AndrewDucker
I'm not sure what the problem is here. Looks like there's a large, very
functional, set of systems that have a lot of reuse.

Would it be better if there wasn't the reuse? Or if the system was less
functional?

~~~
udp
Exactly. This is code reuse done properly, not "dependency hell".

~~~
dcESC
The graph was partially motivated by the experience of compiling a few open
source projects in windows. In Gentoo it's not "dependency hell".

~~~
udp
Why didn't you call it something non-controversial like _"A visualisation of
open-source software dependencies"_ instead of _"A nice picture of
(dependency) hell"_ , then?

~~~
dcESC
Sensationalism? If you would like a post with a less controversial name, have
a look at "High resolution dependency graph".

Sorry if you felt cheated by the title :)

------
henrikschroder
Meanwhile, over in Windows land, I'm trying to remember when I last
encountered DLL hell. It's a long time ago now. People simply stopped trying
to install DLLs in the system directories and just ship all their
dependencies. With the amount of RAM available now, it doesn't matter if you
load 100 different versions of a shared library, you're not gonna notice the
difference anyway.

~~~
udp
In my opinion, that's the very definition of dependency hell - when the system
is so badly designed, software is forced to bundle _everything_ and never
share it.

~~~
bunderbunder
On the contrary, bundling in your dependencies is the very definition of good,
user-centric design.

Disk space has now become so cheap that there's really no tenable excuse for
shipping your software with "some assembly required" and "batteries not
included" labels. Which is why pretty much every major platform has quit doing
it. The lone holdouts are linux distributions. And even they betray their
implicit agreement that it's bad design when they resort to employing ungainly
feats of contortionism known as "package management systems" in an effort to
duct tape over the problem.

------
eonwe
When dependencies are shown on the rim of the circle, most of the area is used
by the circle.

You might want to try to do some automatic force-based layouting instead for
the most dependent-on packages would be easier to see.

~~~
dcESC
I am doing something like that. Look at the zoomed in graph, there you will
see the more connected packages are further away from the rim.

Maybe I can give more connected packages a larger angle to occupy?

------
garethsprice
Is there a single package at the center of this chart that requires every
single other package to be installed (either directly or via sub-
dependencies)? If not, what does the most complex version of _that_ chart look
like?

My assumption is that this is multiple dependency networks being displayed but
that the networks are not all interdependent - eg: dev/ruby does not require
dev/perl or vice versa.

It's an interesting exercise, but it needs justification to define it as
representing "dependency hell" and not just a visualization of a complex
system.

Also, to be read in a Crocodile Dundee voice, that's not a dependency, _this_
is a dependency: [http://thedailywtf.com/Articles/Enterprise-Dependency-The-
Ne...](http://thedailywtf.com/Articles/Enterprise-Dependency-The-Next-
Generation.aspx)

------
dexen
Having explicit dependences on shared libraries in packages was taken straight
from playbook of some Department of Redundancy Department. For any dynamically
linked ELF binnary, the loader (/lib/ld.so or similar) notifies which
libraries are missing upon execution. It doesn't take much to locate relevant
library packages... Resolution at runtime could be mostly automated; say a
dialog asking ``Install 5 packages (15MB in total) now? [Yes] [No]''. Probably
same goes for modules of Python, Perl etc.

I recall Vim being marked as requiring Perl, Python and a half dozen other
heavyweights (in PLD distro) simply because it had some _optional_ support for
those. Attempting to recover half-upgraded, half-broken system over slow
connnection really sucked.

~~~
cperciva
_It doesn't take much to locate relevant library packages... Resolution at
runtime could be mostly automated; say a dialog asking ``Install 5 packages
(15MB in total) now? [Yes] [No]''._

You're joking, right? When I set up a server, I want to set it up and be done
with it.

------
rmc
This could be interesting, but there is too much noise and not enough signal.
All I can see is a large multicoloured circle. Why not try to process it a bit
more so that this could teach us something?

~~~
dcESC
I agree. The graph on the site is already processed a bit, but not enough.

Can you make any suggestions as to how I can make it better?

