Issues regarding UNIX software package managment have brought us many usable, yet complicated package management tools, such as those seen in RedHat Linux, Solaris, BSD systems and Mac OS X. While being very useful at their tasks, they bring unnecessary complexity of the management software used, as well as dependency on central package database.A larger list of problems with the current package management schemes can, probably, be found elsewhere. Here we will concentrate on few ones, as the main task of this paper is to propose potentially more elegant and, first of all, usable solution
to package management problems.
First problem is package installation, or, at least, gaining access to package contents. Many modern systems use either variations of well-established formats, thus producing new format that is similar, yet can not be dealt with using conventional tools (RedHat RPM), or using unaltered format whose nature is somewhat concealed from the user (Debian DEB/cpio). While there is, actually,
nothing wrong with Debian approach, RedHat approach leaves us another “support entity”.
Second problem is package removal. As long as package contents is merged into the existing filesystem structure, a database of package contents is necessary for a safe and full deinstallation. Whether package contents is stored in the central database, or in database unique to each installed package, this accounts for another “support entity”.
Third problem is the coexistence of various versions of the same package. While idealogically unnecessary, sometimes this is the only way to do “smooth upgrade” on a living system. And we know that sometimes system uptime and availability is much more precious than idealogy.
At last, complexity of support software brings us another “support entity”, thus driving the final nail in the coffin of easy portability, and, which is much more important, in the coffin of the KISS principle. Rarely we can perform abovementioned operations easily without resorting to the third-party tools.
The package system proposed in this paper is supposed to solve at least four problems mentioned above, while make it easy to implement mode advanced features such as dependency tracking. These features will be, with some degree of probability, addressed in future revisions of this document.
Cornerstone problem, that of semi-portable package formats and support tools, is solved by using standard tar format (whether with gzip/bzip2 compression or not) for package files, and simple shell scripts as a management tools. While management tools are used, operations they perform can be easily done with standard UNIX tools.
Deinstallation problem is solved by using installed package hierarchy somewhat similar to the one used in Solaris and the one proposed in Linux FHS. Every package is installed inside its own subdirectory inside, say, /opt or /usr/opt filesystem. Thus, package install prefix will be something like /opt/name-version. This brings us the following problem: what to do with numerous search paths for binaries and libraries?
We can solve this problem by using the feature readily available in BSD systems and, as far as it known, in Linux since 2.6 kernel version. This feature is called “union mounts” in BSD, and, probably, something else in Linux.
In order to avoid unnecessary long search paths, we simply remount each package directory under, say, /usr/local, while making sure /usr/local stays at the top of the union, so any additions to it, whether intended or unintended, not end in some unfortunate package”s own directory.
Using discussed /opt scheme we can easily install two versions of the same package, and have at least two options for smooth transition: whether simply not mount the old directory, or mount the new one over the old. The latter option also allows us to do somewhat “incremental” upgrades. Furthermore, if two versions are so distant that they do not collide much, we may leave them both to support sometimes weird software dependencies.
Package deinstallation is as easy as “rm -rf”, assuming we do not do extra things like dependency checking, or do them by hand. Installation, on the other hand, is as easy as “tar xv[z][j]f”. Rolling your own package is similarly easy, you just make a tarball of already installed package”s directory under /opt filesystem.
The catch is that, your system has to support union mounts. As of BSD systems, they have it from long ago. Recent Linux kernel 2.6 is also promised to have this feature.
Please feel free to propose any additions to this document, or comment on possible stupidity of the overall idea, if such stupidity actually has place.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.