A nice picture of (dependency) hell
disfunksioneel.blogspot.com
A nice picture of (dependency) hell
1–10 of 25 posts
Re: A nice picture of (dependency) hell
#2Having 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.
Re: A nice picture of (dependency) hell
#3When 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.
Re: A nice picture of (dependency) hell
#4Having 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 (15M…
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.
Re: A nice picture of (dependency) hell
#5I'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?
Re: A nice picture of (dependency) hell
#6Meanwhile, 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.
Re: A nice picture of (dependency) hell
#7I'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?
Exactly. This is code reuse done properly, not "dependency hell".
Re: A nice picture of (dependency) hell
#8Meanwhile, 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.
Re: A nice picture of (dependency) hell
#9I'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?
Exactly. This is code reuse done properly, not "dependency hell".
The graph was partially motivated by the experience of compiling a few open source projects in windows. In Gentoo it's not "dependency hell".
Re: A nice picture of (dependency) hell
#10Meanwhile, 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.
.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.)