Spk is comprised of a set of shared libraries that implement a package management system and a command line application to interface with that system. The gist of spk is that it executes installation commands for you and records the results. These commands can be anything - from 'touch x' to 'make install'. As the commands are executed, spk interprets what is happening to the filesystem into "records". These records come in three sizes: add, change, and remove. So the basic idea is that after you install a software package, you have a list of files that were added, changed, or removed during the installation. This list goes into the repository under a subdirectory named after the package installed.

Records queue up until you tell spk to process them. They may be applied to a new package or "appended" to an existing package. In either case, the final records list will be in its simplest form - i.e., an "add" followed by a "remove" for the same file is cancelled out, an "add" followed by a "change" is still and "add", a "change" followed by a "remove" is just a "remove", etc.

Spk will also back up changed or removed files during an installation. These get stored in the repository in the packages subdirectory. These files can be restored when the package is uninstalled. Spk should display a warning if files do get archived during an installation.

Spk allows you to list packages, view their contents, and do other package management things. And if you do a verbose system query - spk will scan the filesystem and list files that are not under package management. (This should probably be a separate option rather than the verbose output of another - I may change that soon.)

Spk uses the configuration file $(sysconfdir)/spk.conf. In it you can turn off file archiving (so you don't have to pass the --no-archive switch) and tell spk to ignore certain files or directories when recording an install and to to ignore certain files or directories when scanning the system for unmanaged files.

Spk works by setting the LD_PRELOAD environment variable before it executes commands. This allows it to overload particular libc functions and thereby keep track of what's happening. Because of this, however, your system's executables that install files (install, mv, cp, ln, etc.) must be dynamically rather than statically linked to libc.

If you have any trouble or you have comments/questions, please email me at <spk@christophercarroll.org>.