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.
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.
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?
It is a dependency hell, ready to fire at the moment one of the packages changes its interface (API, behaviour, file layout, ...) recursively breaking a fraction of its dependents. Then you end up with multiple versions of the same package, versioned libraries, private copies of libraries and tools, and so on.
Reuse works great on a small scale, but otherwise requires a lot of discipline both from the provider (who must refrain from interface changes, or have support for multiple versions from day one), and the consumer (who should be very considerate on which packages and features he uses).
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.
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.
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.
.NET actually made a pretty good effort in addressing this with strong names and assembly signing. Unfortunately, .NET is probably not all that common for mainstream consumer apps (I may be wrong here, please correct me if so.)
In that case, you can link as well everything statically. That's what one of my open source projects is about. [1]
Linking everything statically works usually quite well, except if you use libraries that make some assumptions about being dynamically linked (e.g. GTK+).
The benefit is that you have one big EXE file for which you don't even need an installer. Also, it is usually smaller than the previous bunch of DLLs because static linking omits code that won't be called anyway. You can even run an EXE packer [2] on your result, making it even small and easier to deploy. The total memory usage, however, stays the same, of course.
The downside is that you need a good build system for that.
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?
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.
24 comments
[ 4.5 ms ] story [ 54.6 ms ] threadI 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.
You're joking, right? When I set up a server, I want to set it up and be done with it.
You might want to try to do some automatic force-based layouting instead for the most dependent-on packages would be easier to see.
Maybe I can give more connected packages a larger angle to occupy?
Would it be better if there wasn't the reuse? Or if the system was less functional?
Sorry if you felt cheated by the title :)
Reuse works great on a small scale, but otherwise requires a lot of discipline both from the provider (who must refrain from interface changes, or have support for multiple versions from day one), and the consumer (who should be very considerate on which packages and features he uses).
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.
[1] http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx
Linking everything statically works usually quite well, except if you use libraries that make some assumptions about being dynamically linked (e.g. GTK+).
The benefit is that you have one big EXE file for which you don't even need an installer. Also, it is usually smaller than the previous bunch of DLLs because static linking omits code that won't be called anyway. You can even run an EXE packer [2] on your result, making it even small and easier to deploy. The total memory usage, however, stays the same, of course.
The downside is that you need a good build system for that.
[1] http://mingw-cross-env.nongnu.org/
[2] http://upx.sourceforge.net/
Can you make any suggestions as to how I can make it better?
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...