begin quoting Tracy R Reed as of Mon, May 14, 2007 at 08:57:47PM -0700: > Bob La Quey wrote: > > On 5/13/07, Stewart Stremler <[EMAIL PROTECTED]> wrote: > >> No, it can't prevent dependency hell (that's a problem with programs, > >> not with systems) -- it *CAN* prevent DLL hell (or so it seems from > > > > IMHO your first statement is wrong. Systems are collections of > > programs. Programs are collections of data (source code) > > Notice he says that dependency hell is a problem with programs and not > with systems. This is key to understanding his point.
Indeed it is. > Stewart has a different definition of "dependency hell" than the rest of > us. His idea of dependency hell is a program like Subversion which > requires a dozen or two different libraries which he doesn't have > installed on his ancient Solaris 2.6 box which are a pain to obtain, > compile, and install since they also tend to have dependencies > themselves. There's the key. It's not that a program A depends on a library B, C, and D... but that C depends on E, E depends on F, F depends on G, D depends on G, H and I, and G depends on J. > He seems to like programs which use no or very few libraries > and those libraries should be easy to get and install. He seems to see > dependency hell as a path specifically chosen by the programmer when > they choose to utilize a dozen different libraries in their application. It's a choice of the programmer, yes. (Or the management, which says "thou shalt use X, Y, and Z".) It's not just the width of the dependency tree, it's also the depth that results in the "hell" moniker. The more dependencies, the more fragile a system becomes. Fragility is NOT a desirable feature. > Is this more or less correct, Stewart? :) Aside from the fact that I do not have any Solaris 2.6[1] boxes, it's not far off. "DLL hell" is when there are multiple competing and incompatable versions of the same shared (dynamically linked) libraries; attempting to describe /that/ well-defined problem as "dependency hell" is confusing, because "DLL" equates to ".so", not "dependency". UNIX basically solved the library-dependency problem long ago, by allowing multiple versions of the same library to be installed. I suspect that pkginfo/pkgconfig breaks this "feature" and introduces the joys of shared-library hell to UNIX-land, but I haven't verified this, so ingest salt as necessary. It's an odd tradeoff. On the one hand, dependency hell, as I see it, wastes disk by requiring me to install dozens of libraries that are often only fractionally used; the justification for using such libraries is that it's "code reuse" and that it will "save disk space". Further, the use of third-party libraries means that it's easier to upgrade all applications that use said libraries, "increasing security", except that it also vastly increases the amount of code exposed to hostile parties, which therefore decreases security. I wonder if NixOS would allow for universal static linking? That would seem to fit the functional model better than shared libraries... [1] Old Slackware and Redhat, yes. Also machines with minimal extra disk. -- Clarity first. Consensus second. If everyone else is wrong, don'g go along. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
