feed me

  • Subscribe with Atom
  • Subscribe with RSS
  • Find out more about feeds


mt poweredCreative Commons License



Package Management 101

September 26, 2004

I've been thinking about this problem for a while now. I spend a fair amount of time maintaining various systems across all three major platforms: Windows, OS X and Linux/BSD. I have conclusively decided that package managers in Open Source environments are bad, unhealthy and frustrating to use. They aren't just bad around the edges - they truly suck. Here's why, and how to fix them.

Package management is all about making maintaining a system trivial. It means that you can keep up-to-date with latest security and feature releases without having to spend a significant amount of time-bandwidth downloading, unarchiving, relearning the install process, and then configuring, making and finally installing -- that's 6 steps to upgrade something you already had there. Upgrade means to go from one release to another, more recent release. It does not usually mean 'reconfigure' but it certainly means 'alert me of new features / changes of behavior'. You don't want upgrades to be always silent.

Clearly installing-from-source every time is not a viable solution. It's too much work. Whilst you'll always usually get the best setup, you're not going to be actually able to use it since you're spending all this time making it work. There is one other alternative currently on the market. That is the job of a package manager. These range from Microsoft's Window's Update functionality to Apple's OS X Software Update, to more 'raw' managers such as Red Hat's up2date/rpm and Debian's apt-get/dpkg, and finally BSD's port family.

Using these isn't so easy either. If you are on the windows platform, you can either use windows update, or choose to remain unprotected. On OS X, you use Software update, or go it alone, with probable disastrous results. But with the Open Source family of packages, the story is a little different.

The user is presented with the awesome power provided by having absolute control of which packages to be put where. Actually, this isn't awesome control - this is the only option - the user really does have to have some kind of almost god-like knowledge of the system to be able to use it. It is possible to achieve a level of silence from the package managers, though, but to do so you have to accept in blind faith that the configuration options provided by the distributor are good for you. Sadly, too often they are not. There is no happy medium.

Take my recent subversion installation adventures. I'm trying to install subversion client, which has a number of dependencies. I don't want to have to spend time configuring from source: I did that on another box six months ago, and I don't have time to do it again. I just want to get svn installed without having to do any work, but with a reasonably sane configuration. I'm using RedHat enterprise, which is a reasonably average-yet-stable operating system to start from. First, i tried up2date, to learn that there are no packages called svn or subversion. Ok, it's fairly new and clearly no-one at redhat has built and qa'ed a spec yet. I'll bug them about that later. But other people have, so I resort to rpm. Of course, i have to deal with the dependencies, and, one of these is apr. APR is not installed as a package itself, but it's part of httpd. Here are my experiences:

% rpm -qa|grep apr
% rpm -qa|grep http
% rpm -e `rpm -qa|grep http`

redhat-config-httpd-1.1.0-4&38;38;38;gt; ~error: Failed dependencies:
httpd-mmn = 20020903 is needed by (installed) mod_perl-1.99_09-10.ent
httpd-mmn = 20020903 is needed by (installed) mod_python-3.0.3-2.ent
httpd-mmn = 20020903 is needed by (installed) mod_ssl-2.0.46-25.ent
httpd-mmn = 20020903 is needed by (installed) php-4.3.2-8.ent
httpd-mmn = 20020903 is needed by (installed) mod_authz_ldap-0.22-3
webserver is needed by (installed) webalizer-2.01_10-15.ent
httpd &38;38;38;gt;= 2.0.40 is needed by (installed) mod_perl-1.99_09-10.ent
httpd &38;38;38;gt;= 2.0.40 is needed by (installed) mod_python-3.0.3-2.ent
httpd = 2.0.46-25.ent is needed by (installed) mod_ssl-2.0.46-25.ent
httpd is needed by (installed) squirrelmail-1.2.11-1

Yowzer! all this to remove a package which I know contains another package I need to remove because of conflicts? What is httpd-mmn? so on and so on. Fink is another great example. It's like apt but for OS X, and like apt, it has a habit of infuriating me whenever I come to use it. Recently trying to install subversion managed to make fink believe I had 64 other dependencies to install first. 64?? That's crazy. I don't need X to build subversion, nor do I need ruby (though i'm glad to have it)!

These are just two examples of 'bad practice' in package managers. They exemplify the horrific nature of the all-in-one approach that so many managers feel they must provide. Yes, you could answer '"read up on how the thing works, it can solve this for you", or, more pragmatically, "just man manager" (although, quite frankly, i'm getting tired of hearing that answer). I think these are just quick-escapes. I think we really do have a poor system, which is unfriendly to users old and new. I think that we should all do better.

Here therefore, is my manifesto for a better package manager:

  1. Don't make it hard. Users don't want to have to jump through hoops to get a simple tool. These users may be developers who have a high level of Linux/BSD knowledge, but don't have time to waste screwing around with a package manager.
  2. Don't assume stuff. I might not want to have mod_optional_hook in my apache, so why do you force me to install it and then go 'un-configure' it? This is loosely coupled with:
  3. If in doubt, ask. There is no harm in collecting user preferences during install time. Just try to be intelligent about it and don't bother the user - keep it quick, simple and easy to use. (e.g. that means allow for backspace on user input so that if i typo, i don't get foor^? or similar).
  4. Learn. It's really important to ask once, and remember. That's also not so hard. I don't mind spending a while configuring a package once, but i don't want to ever have to do it again, unless there are changes to the configuration options. That's easy enough to parse from ./configure --help -- it's usually a pretty standard format, at least until a database of configure options is built.
  5. Any package manager MUST work cross platform. Package managers don't need to be distribution dependent. They should be bootstrap-able, i should be able to download a package (binary or source, but binary should be in case there isn't a developer chain on the target machine) and simple install the package, run it in bootstrap mode so that it will create initial configuration models (and, for bonus points, why not provide an ability to synchronize basic / local settings from other (base) servers so that i don't need to setup my preferences on new machines?
  6. PMs should know where to look for packages. We all hate how sourceforge makes us navigate and find package download locations. It really is annoying to have to browse for it and get to a point where it downloads the package, when really you want to curl or wget it to your server.
  7. Packages should auto resolve dependencies, or co-exist. I don't care if you need httpd or neon or whatever dependency - iI just want to install the thing.

I am sure there are more to add, however this is a good start. We should work hard to find a package manager solution which can effectively deal with all our requirements, and in such a way that we do it in a non-partisan and effective method. I look forward to your comments!


post tools


Couple of 2p's about this from little ol' me:

1. One thing I really miss since moving over to OS X from Debian is the lack of ability to search lists of available software that I want to install. Names of software packages aren't always intuitive as to what they are, but a 'apt-cache search blog rss' is likely to suggest a number of different solutions. As well as suggesting which packages are available apt is nice enough to download the latest available version from the net.... not many package managers do this (up2date has a go, but there aren't that many packages available)

2. Your example above of svn requiring X is the fault of the package maintainer not the dependancy resolver.... Both Red Hat and Debian seem to be littered with illogical dependancies (although they may be obvious to the maintainers ;) )

3. Red Hat isn't a dependancy resolver anyway... I remember a protracted discussion about this on GLLUG last year >> http://lists.gllug.org.uk/pipermail/gllug/2003-October/039043.html

4. I agree with everything else!!!!! These package maintainance systems need to ask smarter questions for people who don't know/don't care/don't have time to answer them.


Amen Brother!

I know this doesn't fit all of the points that you made (most notably fails on #5), but since I discovered Debian and apt, I haven't looked back.

1. Apt is simple
2. it doesn't assume anything (unless you tell it to) and you can even use it to reconfigure packages that are already installed (dpkg-reconfigure)
3. it asks questions based on preferences that you set
4. it remembers your preferences (even if you have it set to ask you questions, it will have your most recent choices listed as the default answers)
5. It does work cross-platform, but that functionality is dependent on a proper repository being available, and I haven't personally found a good central one for anything but Debian itself
6. It always knows where to get the packages, as long as they're in the repository, and you can add third party repositories if there is something that's not in the distribution.
7. apt does autoresolve dependencies, and since your packages are pulling from a repository where they've all been compiled and tested to work together, they can all pretty much co-exist.

It's by no means the perfect solution, but it's as close as I've found :) It took me a long to try Debian/apt, and I was beginning to hate Linux specifically because of the broken way that it handles packages and dependencies in almost every distro.


I thought apt would be the right solution, until i realized that it just didn't like me if I happened to install my own version of apache. (actually, that's not true; it didn't mind that much. my mind is probably tainted due to fink).

Still, trying to install qmail via apt was a chore.

Just a comment about svn on Mac OS X using Fink:

You state: "I don't need X to build subversion, nor do I need ruby (though i'm glad to have it)! " and you are correct! But you didn't use Fink the correct way! ;)

Try 'apt-get update' 'apt-get install svn-client-ssl' and you won't need X nor ruby. Those are only needed if you want to build the package yourself using 'fink install svn-client-ssl' since it builds all the related packages at the same time. But even then all these extra packages can be removed again after the build is finished.

Now, where i agree with you is the following: This should be easier! I am working on a patch to fink right now that will enable the fink command line tool to decide if a package is available via apt-get and if yes just install it instead of stupidly recompile everything.

Fink is partly based on apt. So, most of the apt tools you know work if you have fink installed.

I hope this info makes things a little clearer.

Chris -

Yes, that'd work, but it contravenes the point - I really don't want to have to screw around jumping through hoops to simply install svn.

The process should have been like:

% fink install svn

fink... analyzing packages...

Do you want to install the server or client version?

client chosen...



(ok, so that's a little pseudoish) but you should get the idea. I think that the KISS philosophy is what should apply here.

Fink versions since 0.23.0 (currently in unstable) now have a '--use-binary-dist' switch. This tells fink to try to download the package and its dependencies from the binary distribution, if available. It can be enabled on the command line using 'fink --use-binary-dist install svn-client-ssl' (or 'fink -b install ...') or, even better, in the fink configuration. Set it by calling 'fink configure'.

It is documented at: