D. J. Bernstein
The /package hierarchy

Package management

A package manager keeps a database saying which files are in which packages. It provides some useful batch operations on the database. One operation is to extract a package from a tarball, simultaneously adding the package's files to the database. Another operation is to remove all the files in a package, simultaneously removing the package's files from the database.

Most package managers don't provide any other operations: for example, adding new files to a package, or declaring that some existing files form a package. What happens if a developer compiles and installs a program, and wants the program to be registered with the package manager? He has to collect the installed files into a tarball, remove the files, and then feed the tarball to the package manager. If he adds another piece to the program, he again has to collect it and remove it and install it.

In contrast, /package reuses the filesystem as the database:

Package directories are identified as non-sticky subdirectories of /package, and non-sticky subdirectories of sticky subdirectories of /package, and non-sticky subdirectories of sticky subdirectories of sticky subdirectories of /package, and so on. For example, /package/admin is sticky, and /package/admin/daemontools-0.76 is not, so /package/admin/daemontools-0.76 is a package directory. /package itself is also sticky, to simplify scripts.

By convention, package tarballs unpack in /package, and they include all necessary subdirectories, so that system administrators do not need to create directories in advance. For example, the admin/daemontools-0.76 tarball includes a sticky admin directory as well as the admin/daemontools-0.76 hierarchy. Note that tarballs have to be extracted with tar -xpf, not tar -xf, to preserve sticky bits.