posted by Karl Zollner on Wed 4th Aug 2004 18:26 UTC
IconWhat follows in the article is an analysis of the "dependency hell" problem in Linux and the issues surrounding software installation. I make a proposal of my own and critique the suggested "solutions" to these problems and point my finger at "the" (my perception) source of these problems.

I have used Linux for almost 8 years now and exclusively for the last three, so I have experienced what many refer to as "dependency hell". Two years ago I switched to Gentoo which radically reduced my experiences with dependency hell. I will not say it eliminated it-for I love to play with the very newest and latest, but as regards those packages in portage I have had extremely few dependency problems -read perhaps 3 times.

In fact my experience with Gentoo has been so positive that I doubt I will ever use a binary distribution again-except the one I roll for myself. With this as a background you can probably imagine the immediate utility of "grand solution" to "dependency hell" for some one like me: ie. negligible.

Yet I wish that some of what I have grown accustomed to in Gentoo would be available to those who use the major distributions: for one it might stop the endless tirade of "Linux needs a good installer" posts and much more importantly prevent draconian changes to Linux in the name of a "grand solution" to dependency problems. This article, however, is not about Gentoo, nor about it's virtues and vices. It is about possible approaches to this massive beast of a problem.

I do understand that the vast majority of Linux users do in fact use binary distributions and that there is a need for a viable solution to creating cross-distro binary packages. I also understand the plight of software developers in general and commercial developers in particular as regards offering their packages in an easy to install format, regardless of the distribution and version they are using.

I also understand the importance of things like LSB for the really large distros-those who are seeking certification by governmental bodies and standards committees and who are working closely with giants like Oracle. Yet after having read the article by Arvind Narayanan and other recent articles about the LSB that there is a) a lack of creative problem solution b) that the "solution" may in fact be worse than the "problem" itself and c) that beating this dead horse with a stick again isn't going to make it go anywhere.

I have also closely followed the development of Mike Hearns' Autopackage project and Thomas Leonards' Zeroinstall project. These projects are attempts to solve some of the issues of "dependency hell" which think "outside of the box" of the conventions already established in the Linux community.

So without any further ado I wish to make some of the following observations and possible alternatives and solicit a response from you regarding your take on such and whether or not others in the community have been talking about such.

Lets start with the basics. Where does "dependency hell" come from. Dependency hell occurs when an application requires a multitude of tightly interdependent libraries and those versions expected by the application conflict with previously installed software on the system or when other applications require the same libraries but with different version numbers. This is how the "users" experience dependency hell. Being as it is that most free software makes liberal usage of existing libraries (code re-usage) the potential for "dependency hell" is given. However this situation is compounded again and again by issues which are external to any particular application itself-

Distribution specific collections of default installed libraries. SuSE, Redhat, Fedora, Mandrake etc. are markedly different in the specifics regarding which versions of which libraries are installed by default.

Distribution specific attempts at wider-scale integration of software which mandate exactly which libraries are compiled with which specific features and which specific patches.

Intra-Distribution version schemes and the correspondingly different constellation of installed default libraries. Major distributors pursue branding schemes which compounds such problems beyond the differing rates of development of the effected libraries.

These issues are homegrown issues brought on by the distributors themselves-they are responsible for this situation and they are obligated to finding ways to alleviate this situation. To the extent that they amongst themselves can work towards standardization via things like LSB they are working towards minimizing the negative costs of their market driven choices. Inter-distribution incompatibility is primarily a function of being market driven: built-in incompatibility is the key to all forms of customer lock-in, this is a trick they learned from their proprietary cousins. One does not have to be cynical to understand the market importance of branding and the most effective way to pursue such branding is to create distributions which differ sufficiently that users are bound to that distributor for the software of their choice.

Table of contents
  1. "Dependency Hell, Page 1/3"
  2. "Dependency Hell, Page 2/3"
  3. "Dependency Hell, Page 3/3"
e p (0)    104 Comment(s)

Technology White Papers

See More