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.
Alex Botero-Lowry (email@example.com) 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 (firstname.lastname@example.org) 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.