Havoc's Blog

Eugenia was recently reminding me about the “dependency hell” problem
when trying to install random Linux software found on the Internet.

Joel’s
latest article points out once again that the cause of dependency
hell is dependencies. Mike Hearn points this out too
(though I’m still not convinced a new package format helps).

Here’s how you get rid of dependencies: you have one or a small number
of big monolithic chunks – the LSB defines a core one – and apps can
depend on that, and nothing else. Everything else has to be shipped
with the app itself, or be optional and detected at runtime. An app
can require “Linux,” not a huge list of files and libraries.

An implication: packaging of distribution components (things that go
with the distribution itself) and packaging of third-party apps is
fundamentally different.

A corollary is that it’s kind of nice to have as much as possible in
the distribution itself, or packaged specifically with one
distribution release in mind.

I don’t think people are facing up to the fact that there’s an
unavoidable tradeoff here. Extra copies of the same code
means bloat, difficulty of doing security and bugfix updates, lack of
consistency, and so forth. Dependencies mean dependency hell. For
each package, pick which one you want; there’s no magic technical
solution.

Some open source projects design themselves to be part of
distributions and some design themselves as third-party ISV
products. GNOME for example is clearly designed to be part of the OS,
not installed by random end users, and I consider this correct for a
desktop platform. Discussions of how to move forward in GNOME 2.8 show
this trend continuing – to make the desktop work right we have to get
increasingly entangled in distribution details such as HAL and CUPS
and so forth. The big previously-proprietary apps such as
OpenOffice.org and Mozilla have a very different attitude and tend to
assume end users will install the app themselves. Which is both true
and untrue on Linux; some will try the app themselves, and some will
get it with their distribution.

If you buy what
Joel is saying, then adding new stuff to the big monolithic core
(call it LSB, or just “Linux”) and getting third parties to use it
takes ages. This rings true for me. Very few ISVs use libraries
beyond the C library and the occasional GTK+ or Qt. I’m pretty sure
most Red Hat customers are still using Red Hat Enterprise Linux 2.1 –
which was released over two years ago, with GNOME 1.x, based on Red
Hat Linux 7.x-era technology. (This may have changed since we’ve been
selling a lot of subscriptions lately.)

Things are tough for third-party apps; they have a lot of dynamic
adaptation to the current environment, and tend to dlopen() things
rather than include a hard dependency. This can mean implementing the
same functionality multiple times over for different Linux versions.

Apps that are part of the OS on the other hand can use new OS features
and have dependencies left and right, as soon as those dependencies
are available. These apps have a real technical advantage, but have
the disadvantage that people only get new versions when they upgrade
the OS.

You might expect from this that OS components advance more
quickly but become widespread more slowly than third-party
apps. I wonder if that’s empirically true.

(This post was originally found at http://log.ometer.com/2004-06.html#16.2)