>Unix Packaging

>First off I prefer to have to learn the least number of tools possible to do any given job. Hence I want this idea to get rid of the need to learn apt* and friends. I like apt, however I like elegance more. I will leave it to the reader to determine if they think this idea is more eloquent.

This simple (and fake) howto will show you how to manage your system using the package file system.
Install a package:

# cp /pkg/rep/us.ubuntu.com/applications/cheese /pkg/installed/

Find out package description:

# cat /pkg/rep/us.ubuntu.com/applications/cheese
A tool to take pictures and videos from your webcam.
Cheese is a cheesy program to take pictures and videos from your web
cam. It also provides some graphical effects in order to please the
users play instinct.

List installed packages:

# ls /pkg/installed

Yes. Everything I just did is doable today. However this let’s you use standard tools to manage your packages. Basically all I say is “every package is a file”.
-Now available for proper criticism :).

3 thoughts on “>Unix Packaging”

  1. >Where do errors go? You can change the system calls for a filesystem to do weird things, but you can’t universally add arbitrary errors to system tools.

    Is memorising commands for apt-get (like the one everyone forgets: install) more difficult then remembering a several system commands and dirnames?

    Thanks for writing it up anyway,


  2. >Using the file system as a deployment mechanism for software is actually quite doable, and has been done before. Carnegie-Mellon’s Andrew and Coda file systems were designed specifically to support a global file namespace, and did, as I understand things, host compiled packages for people to cp(1) onto their local disks. While AFS and especially Coda were designed to support this kind of use, in principle, any file access protocol could be used as the substrate for such a package installation system. (Well, maybe: it would be desirable for the underlying access layer to support a reasonable amount of Unix file system semantics and metadata; for example, the capacity to list directories is important for ordinary Unix programs to poke around in the repository, and permissions and ownerships are very important for functionality and security.)

    However, there are some gotchas, both in your writeup and in the general approach. First, I think from your writeup that you want cp(1) on some filename to cause a bunch of files to get placed under /pkg/installed/, that you want cat(1) on that same filename to print some text. But both cp(1) and cat(1) are basically just byte copiers (ignoring cp’s support for sparse files); to a first order approximation, cp(1) can be implemented as cat $source > $destination. So your proposal would either require having cp(1) and cat(1) special case certain areas of the file system, or else require beefing up the Unix system call interface to have calls like open(2), read(2), etc. do some special things under certain probably-vaguely-selected circumstances. But note that cp(1) and cat(1) aren’t the only programs that can copy bytes: so can dd(1), mv(1), tar(1), cpio(1), sed(1), perl(1), tr(1), emacs(1), etc. So if you want special magic behaviors when operating on filenames in the package repository and installation areas, you’ll have to make an arbitrary decision about which unpredictable behavior should be expressed for each program that can do I/O. In my opinion, it would be highly preferable to have the package repository appear as an ordinary, non-magical, read-only file system, so that your cp(1) invocation would instead have to be “cp -pR”, and your cat(1) command would have to be something like “cat /path/to/package/.description”. Yes, you’d have to learn something about the package system to use it, though the stuff you’d have to learn wouldn’t be new commands, but instead some conventions about file system layouts (which are investigatable, and so better than special-case behavior for programs all over the system.) So I think you’re misinterpreting the slogan “everything is a file”: you’re proposing something along the lines of “there should be a file F such that for all operations on a package in a repository, supplying F as an operand to the operation does what I want”. Instead, I suggest that the appropriate interpretation is “for every operation O on a package in a repository, there is some file F such that O on F does what I want.”

    Second, and more importantly, putting files into place is only a smallish part of what a package manager does. Among other features of extant package managers include execution of install-time and uninstall-time programs (e.g., to record the program or pieces of the program in various global registries, such as documentation indexes and search paths such as “bin”, “lib”, and “man” directories; or to execute application-specific initialization, such as generating databases, compiling or byte-compiling source files, prompting the user for important configuration details, etc.) Further, package systems that maintain interpackage dependency data can help to prevent broken dependencies at run-time. In a package deployment system built on top of a file system protocol, if you wanted any assurances, even meek ones, about run-time integrity, you’d need tools to ensure that installed packages’ dependencies are satisfied. Loosely speaking, there are three times when dependency checking can be done: (a) install-time, (b) periodically, (c) when the dependency is required. If you’re using a standard Unix program such as cp(1) to put packages’ files in place, then (a) is only possible if the user remembers to do it; but if dependency checking is done asynchronously via a job scheduler, then the dependency check might not get run before the dependent calls upon the dependee, and so (b) in general turns out to be (c), which is what we call “DLL Hell”. So since there’s all this stuff that it’s desirable for a package manager to do, even if packages were accessible via file system protocols, you’d need wrapper programs for this extra business anyway.

    – Marty Kreuter
    erstwhile New Jerseyan

Leave a Reply

Your email address will not be published. Required fields are marked *