Articles / Introducing a Third Option

Introducing a Third Option

Recent freshmeat editorials have dealt with the current state of package management systems. Today, Alex Botero-Lowry and David Eklund look to the future and discuss the work they're doing to create an alternative that draws on the best features of the current "big two".

At this time, there are two options for a good packaging system with all the commonly-needed features: RPM and deb. The Simple Packaging Kit, or SPK, is on a quest to make a third option. Because of SPK's current development state, new features are always coming in, meaning that if we find features that are needed to make SPK a viable "Third Option," we can usually add them without breaking anything.

An SPK package is simply a bzip2ed tarball with data and a configuration file inside. This has its pros and cons, but seems to work well in the end. A major con is that it is slow for querying an SPK just to find its package name and description, because the whole package must be decompressed before the configuration file can be read. The configuration file itself is written in XML because of the language's flexibility and readability. SPK formerly used environment variables from a bash script, but these became awkward to read by hand in larger packages and illogical to use after the SPK management software was switched to Perl.

SPK tries to split everything into categories. This way, the user may choose not to install certain groups, such as documents or man pages, simply by using an --exclude command. This is good for people who are low on disk space. The major problem with this is that the automatic SPK building tool (which automatically creates an SPK from the contents of a specified directory) must assume which category each file must be put into. It puts files into categories based solely on what directory they're in. We are attempting to help fix this problem by having it make assumptions on both the location and extension of the file. Eventually, a graphical interface which allows the packager to place individual files or directories into specific categories would be ideal, as human intervention is necessary for 100% correct categorization.

SPK includes dependencies, but they're done in a way that's different from how most packaging systems handle them. Originally, the idea of SPK was to make it highly portable to already-installed Linux machines. Instead of checking to see if a package was installed, SPK checked to see if the actual file existed. Other forms of dependency checking have since been suggested, including command dependencies (see below). In order to fluidly support the need for various enhancements, SPK is moving towards the idea of modularity.

We have decided to use modules for most parts of the system, including inter-packaging system dependencies, which will be handled by the Meta Packaging modules. Meta Packaging is the idea to make SPK interact with any packaging system as if it were that packaging system. That means that if you install an SPK on an RPM machine, dependencies will work as you'd expect. All of the network functionality will also be offered in these modules. We have not yet decided on the module loader style, or how the modules are to be implemented exactly.

In the future, we hope to work on conflict management using keywords; if all of the keywords of one package match those of another installed package, it won't let you install them both. We are also working on command dependencies, dependencies that are based on the output of a program or script, the possible outputs of which are 1 (dependency fulfilled), 0 (warning), or -1 (dependency failed: fatal). 0 is always preceded by a message, and the user is asked whether she wishes to continue. This could be used for many things, such as CPU speed or amount of RAM. Meta information is also being polished, and things like architecture and PGP signatures are being added.

SPK was created to make a third option in the packaging wars, and we hope it can do that. We have tried to take the best ideas from both RPM and deb. We think we have done a pretty good job and hope to continue work on SPK far into the future.


Download site for most versions of SPK and all the papers that have to do with it:
Download site for the current version of SPK:

Alex Botero-Lowry ( is the Head Developer for Linux Secure Workstation. He is also deep into work on an online classroom for schools. Alex also develops for Stampede Linux, is the official Stampede SPK speaker (talks about SPK from a stampede standpoint instead of an LSW one), and develops the new Stampede initscripts. On the side, he enjoys reading and plays in science and sometimes music.

David Eklund ( is the Assistant Head Developer for Linux Secure Workstation. He is the Lead developer of SPK. SPK is entirely thanks to his dedication to helping with the betterment of the project.

T-Shirts and Fame!

We're eager to find people interested in writing editorials on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an editorial gets a freshmeat t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let know what you'd like to write about.

Recent comments

08 Jan 2001 12:50 Avatar mweers

The two real problems with RPM etc.
Having a mechanism resolving dependency/requirements is fairly standard among package management systems. And this is it that makes e.g. RPM packages incompatible to different distributions. This problem must be resolved, such that users are free to use software they like (and do not have to wait for their distribution to have a package) and even to allow ISV's to use the package management system (maybe also for their commercial software).

What we need is a scheme for unique requirement identifiers that work with every Linux system.

The other thing is that of standard shared library's file names. Although not the fault of the package management system itself, some libraries seem to change their name with every new release of my distribution. My prominent example is the C++ standard library. Here, we also need a more common naming sheme.

07 Jan 2001 11:05 Avatar jkominek

POSIX Packages
How about somebody break down and buy the POSIX packaging system specs and implement that? Why do we need to "standardize" on another packaging format when POSIX has already done that work?

07 Jan 2001 09:52 Avatar elleron

Another cure worse than the disease
This is Classic Mistake #3(tm), a solution to a nonexistant problem.
When comparing packaging schemes, it's fair to compare two things, the package file format and the packaging tools.

As far as rpm and deb go, neither is a particuarly bad format. RPM is probably slightly more capable, with both of them having minor problems. In any case, designing a third incompatible format rather than fixing one of the existing two is the wrong answer.

Tools are slightly more of a Holy War. Apt certainly seems to be the most popular, but rpm is much more capable for some situations. Not suprisingly, those situations also deliniate the typical users of the different distributions. rpm excells in corporate, server-farm type installs while apt shines on the home/hacker desktop. As many people have pointed out, however, either tool could easily work with the other format, so writing new tools is also the wrong answer.

The real issue is that Linux doesn't refer to a platform, or even an operating system, just an operating system kernel. Things like generic dependancies, package categories, etc all need to be decided above the vendor level for any multi-vendor OS. To that end, the right things to focus on are:

1. Getting the LSB to settle on a package format now, not later. There's already a stated "plan of record" to adopt rpm, which seems to have drawn a minimal of complaints. So, enough's enough, adopt rpm as the lsb standard and get it over with.

2. Wrestle away from being RedHat-only and give it a gcc/apache type steering commitee which makes all descisions affecting the file format. I suggest including both RedHat and Debian people and folding the few features .debs have that rpms lack which are generally useful into the next rpm format. The rpm specification should also be extended to provide a definitive set of categories, generic dependancies, etc.

With a widely-accepted and sane format, the tools used won't matter. And, with only one package format to support, more developers will be willing to support it. The entire --nodeps fiasco disappears when the tarball can be coverted to an rpm via rpm -tb tarball. On the same note, most people could care less what package format apt uses, as long as it works.

Additionally, I feel compelled to correct an earlier post that the RedHat update agent is a pay service. It, in fact, will also work in an anonymous fashion. It's a bit flaky, however, and I will conceed that apt wins for network updates.

07 Jan 2001 07:24 Avatar gnea

then again...
strike my previous post down like a hunter shoots down a duck.

you're right, it has to uncompress the whole thing to sift through it to get just that one filename. Very cumbersome. Why not use the old school method of .lsm files? Or hack up something similar?

07 Jan 2001 07:20 Avatar gnea

but, uhm...
A major con is that it is slow for querying an SPK just to find its package name and description, because the whole package must be decompressed before the configuration file can be read.

tar xIvf package.tbz2 file_descriptor_file.txt

tar xjvf package.tbz2 file_descriptor_file.txt (with the new tar 1.13.18)

uncompress the WHOLE package? try reading the manpage sometime, y'never know what sorts of usefulness will popup. ;)


Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.


Project Spotlight


An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.