a place in the sun

about Sun, Solaris 10 and Java Workstation w2100z -- Posts with "sunshine" in titles will praise SUNW, Solaris 10 or w2100z. Posts with "sunspot" will complain. Other posts will fall somewhere in-between.

Home Atom Feed

2005-06-19

wish list for package management system

Because OpenSolaris is to be "base" of Solaris distributions, I started looking into various binary package management systems (c.f. Eric Boutilier's comparison of binary package management systems) While browsing I tried to summarize my wish list for package management system.

Maximalist base packages of libraries

Lots and lots of libraries of many kinds and of many versions. This reduces need for auto-update and dependency checks. With lots of libraries bundled, package creators can focus on binary, configuration and documentation.

Bookkeeping of packages

This feature answers questions "What are already installed?" (trivial), "To what package does this file belong?", "What packages does this package depend on?" and "What packages depend on this package?" (more interesting and useful)

Automatic dependency management and update is a convenient feature but it doesn't seem to work well with large number of packages. If installing a large dependency graph does not succeed, then uninstalling is even less likely to succeed. Also this feature introduces a risk that is difficult to assess: package installation is a blackbox process with root privileges. Convenience of having most up-to-date software is nice, but why stop there? Why not go for "zero installations?"

Namespace management (or relocatability)

It would be nice to be able to install different versions of binaries with "same" name (e.g. various versions of java). Because of Unix's global filesystem namespace, users need to mangle reified paths and $PATH and other variables. Also package creators need to be careful about how they name their packages and how they use paths outside their packages. Strictly speaking, checking for hardcoded paths inside binaries is not a (binary) package management system's job but something somehow better take care of this matter.

User level installation (Issue #1)

If a system supports relocatability, non-root user would be able to install packages under $HOME/ or elsewhere with right permissions. root is overused already and we are not in Windows.

User level installation (Issue #2)

It should be very easy for users to be able to create their private packages fast. For example, users of Python can install libraries by running a standard script setup.py that copies files to python's own library directory. Most of files in the library directory are already from Python package. New files do not belong to some package but it'd be nice to be able to put them in a package for easy maintanence.

For now I am going to stay with good ol' pkgadd and company. A package management system is yet another "trusted computing base" that can suffer from "fragile base problem" (I am mixing metaphors here). I have to trust somebody and Sun seems to be the least objectionable choice. Other package management systems are not bundled and they themselves need to be maintained like any other packages. These other systems have attractive features (e.g. pkg-get has automatic update, pkgsrc namespace and openpkg user level installation) but each one alone is not attractive enough for me to justify the cost of adding one more package management system at this time.

At 16:22 by Jay