Requirements For A Usable Package Manager

Jeff writes:

What I would like to explain is why the impedance mismatch between Linux and Solaris packaging is not so much a technological divide as it is a philosophical one.

Philosophical differences are fine. Infinite diversity in infinite combinations, etc., however, regardless of the philosophy the goal of the package manager should be to make the life of the sysadmin easier, otherwise it’s not much use.

For a change this won’t be a rant about how the package set is an ancient pile of crap, we’ll assume for the sake of this discussion that you’re so concerned about stability you’re willing to live with a 6 year old version of bash. We won’t discuss how incompatible 3rd party sites are a poor substitute for the ports tree, because maybe you’re happy with a 5 year old version of nano.

The point is the tools should be independent of the packaging philosophy. They should minimise the amount of effort required to manage the system – automation is a good thing ™. On that basis, I propose that there is a minimum set of functions these tools should provide.

  • Automatic Dependency Resolution. Pretty obvious, you can’t call anything a package manager if it can’t do this.
  • Simple Upgrade. All upgrades to the packages should of course be available as packages, and there should be a simple command to upgrade all packages for which there is a new version (thanks Cian for reminding me of this one)
  • Remote Repo Support. HTTP is preferable for this, because, everyone has a http server. I don’t want to carry the Solaris 10 DVD in my pocket everywhere, and I don’t want to go around mounting NFS directories. The vendor doesn’t have to provide the package server, just support in the tools for a package server so I’m free to make my own (and, so are others)
  • Support For Multiple Repos. Blastwave has it’s own tools (yes, multiple) to actually install it’s packages. SunFreeWare relies on you doing your own manual dependency resolution (*shudder*). This is a load of shite. The package tools supplied by the operating system should allow me to define multiple sources, and rules for which source should be used. I should be free to build custom packages with dependencies against base packages if that’s what I choose (and, there’s lots of reasons to want to do this), or to maintain a separate hierarchy of independent software (like blastwave etc.) if that’s what the situation requires.
  • Simple tools to query packages, search for packages, query files. We don’t need all the bells and whistles of apt, but, we do need equivalents for ‘apt-cache search’, ‘yum info’, and ‘dpkg -S’.

Regardless of the philosophy, the point of a package manager should be to manage all the software on the system. I don’t have time to compile things, and I don’t enjoy patching things. There is no reason that you can not achieve separation of components, (eg, base and ports) while still providing binary packages for everything. The whole system should be package managed, apart from the handful of shell scripts I have sitting in /usr/local/bin ( the one place the package manager should never touch. /usr/local/ is for me to manage. This is what both FHS and the debian package policy says)

Posted January 29th, 2010 in Linux, Solaris.

3 comments:

  1. Cian:

    You don’t think that your package manager should have to manage patching?

  2. andrew:

    I don’t think there should be any patches to manage, everything should be packaged. Thanks though, I’ve updated the post to make that clearer.

  3. Kat:

    Are you going to make such a wonderful system or are you just dreaming about it?

Leave a response: