The GNU package manager translator

The GNU system discussion group is planning a package manager to implement Stallman's idea which has given motivations for the PackageFS project.

The structure of the GNU system is completely different from the Linux one. The core of GNU is the Mach microkernel and its base system is implemented in the user space by a set of servers running on it. These two components aim to replace the typical Unix kernels and they together compose the Hurd. The Hurd is designed to make the area of system code as limited as possible. Programs are required to communicate only with a few essential parts of the kernel; the rest of the system is replaceable dynamically. Users can use whatever parts of the remainder of the system they want and can easily add components themselves for other users to take advantage of. No mutual trust need exist in advance for users to use each other's services, nor does the system become vulnerable by trusting the services of arbitrary users. All GNU features are provided in the user space by some servers called translators.

A translator is a server that filters requests issued to a specified directory or file. Even if its implementation is completely different from that one of an user space file system, their purpose is similar.

In the GNU package manager design, a user can install or remove a package by making or deleting a symbolic link in $\texttt {/packages}$ directory. This latter has a special meaning: every subdirectory in it is an installed package. Most often it contains symlinks to directories, and they are installed packages too.

Directories such as $\texttt{/bin}$ and $\texttt{/etc}$, where packages could install files, are handled by the GNU package manager translator that makes virtual union operations. Their content may vary following entries found in $\texttt {/packages}$. For example, $\texttt{/bin}$ is the virtual union of $\texttt{/packages/}$packagename $\texttt{/bin}$, and $\texttt{/etc}$ is the virtual union of $\texttt{/packages/}$packagename $\texttt{/etc}$. Furthermore some files behave as virtual concatenations. For instance $\texttt{/etc/inetd.conf}$, which is usually composed of lines added by different programs, could be a virtual concatenation of $\texttt{/packages/}$packagename $\texttt{/etc/inetd.conf}$.

Packages of the GNU package manager translator, are plain source archives that a user can extract and compile anywhere on the system. To install the compiled package, any user would make a symbolic link from $\texttt {/packages}$ to
$\texttt{/}$dir_of_compiled_package. The name of the symbolic link is irrelevant. Instantly the files in $\texttt{/}$dir_of_compiled_package $\texttt{/bin}$ would all appear in $\texttt{/bin}$ and so do the files of subdirectories managed by the translator.

Deinstallation is equally simple: just delete the symbolic link. We notice that neither installation nor deinstallation involves any alteration, copying or movement of the files that actually make up the package.

These are the basics of the GNU package manager translator. There are a lots of planned improvements, but those are not argument of this thesis.

The package manager translator provides simple and powerful package management. Since the Hurd is mainly a user space replacement for the Linux kernel, this new package manager is the most appropriate for the GNU system because the total amount of context-switches is preserved (the whole file system implementation resides in the user space).

Those plans present a new package management concept indeed. Both the translator and PackageFS provide ``by-package'' system view as well as simpler interface to package management. There are three main differences between those projects:

• They belong to different systems;
• The translator is part of GNU package management, whereas PackageFS is only an interface to underlying package manager;
• In GNU, the symbolic links in $\texttt {/packages}$ represent a ``starting point'' from which the system is built. On the contrary even if PackageFS provides access to the system, its symbolic links point to files that already exist (see section 5.1).