Packages representation

First of all, we would like to differentiate available packages from the installed ones. The need of this separation, arises when we consider that an installed package owns some files on the system and we would like to represent them, in order to make PackageFS an access point for real files management. These two kinds of packages have their own directory in the file system. Thus, if a package is installed, it has a directory entry in the $\texttt{AVAILABLE}$ tree and in the $\texttt{INSTALL}$ one. Available entries are created by looking into the packages repository specified in the package manager configuration file, but we will say more about it later. Each time we will explicitly specify the particular package we are referring to.

All packages archives hold essentially files they own and metadata. Since they are containers, they appear as directories. Thus, users can effectively move into packages through the $\texttt{chdir()}$ function (see section 3.3.3.4) and so, for instance, the $\texttt{cd}$ command.

Each installed package directory contains the subtree of all files the package owns. Since PackageFS is more than a simple way to browse packages, each of these files is a symbolic link to the real files installed on the machine. This feature allows to keep straightforward access to package binaries, libraries, documentation and, above all, configuration files. In addition, any user can find out files belonging to a package through the command

• $\texttt{ls -R}$ installed_package_dir

or search for any file owner by

• $\texttt{find INSTALL/ -path}$ pathname $\texttt{-xdev}$

and looking at one of its ancestor directories.

As specified in the Filesystem Hierarchy Standard, any package should create files or directories at root directory level. Thus, we can safely add virtual files just under available and installed packages subdirectories. That is the place where metadata are saved: an empty $\texttt {info}$ file is created. As soon as a user reads it, some package information are shown. They change in accordance with package manager used in retrieving them. In the actual PackageFS implementation, which supports Debian APT, they consist in package name, version, section, priority, dependencies, packages provided, description, the maintainer and the filename in the pool of the packages repository.

At last, in the package root, there are two other subdirectories named $\texttt{DEPENDS\_ON}$ and $\texttt{DEPEND\_FOR}$ . They store respectively symbolic links representing straight and reverse dependencies. Thus, also package dependencies are browseable through an ordinary file manager. Moreover, if they are installed, they point to PackageFS installed package directories, and become another path to access these entries, otherwise they are in ``dangling'' state (their target does not exist) that will be automatically fixed if the administrator installs the corresponding dependency.