Package Management is a Red Herring
March 12, 2007
Package Management is a Red Herring
Traditionally package management has been fairly complicated. Developers must navigate the matrix of platform support, package format and configuration choices that are often as time consuming as they are restrictive.
For instance, the goto format of the day on most Linux platforms is the Debian package format. Debian packages follow closely to the FHS (File Hierarchy standard), and tend to enforce fairly strict Debian packaging policies, such as placing development files in separate packages. Debian packages require the creation of a control file with information about the build as well as a “fuax installation” that is packaged up into a .deb file. All of this takes a fair bit of effort on the developer’s part. And that’s just the work involved for supporting one package format for a limited selection of platforms.
For Ruby developers, RubyGems has come along to make life a fair bit easier. They have dispensed with FHS compliance, to the dismay if Debian maintainers, and provided a relatively easy means of packaging up a library or application for redistribution by following the convention over configuration philosophy. Of course, it helps that the target source is Ruby, which has very simple file-based import system, as opposed to C or Java.
Even so, package management can be even easier if we simply recognize the gorilla in the room: version control systems. All developers now use source code managers (SCM) to track changes to code and distribute source between developers. See the keyword there? The ability to distribute a program is half the battle of package management.
The other half is installation. For a pure-Ruby program installation if fairly trivial, it’s just a matter to putting the files in a proper location on the file system. For C or Java packages there is the further matter of the compile. For open-source projects that’s not particularly difficult, a build script can be provided and as long as the end installer has the necessary build tools, the program can be compiled on demand. For proprietary code it gets more complicated, but lets put that aside for the moment.
Taking all of this into consideration, packaging systems should be fairly trivial –a wrapper around SCM tools that pull down the current or tagged version of source, run the build script and copy the resulting files to an appropriate place on disk. Such a system would be very light weight. In fact, with the exception of dependency management code, there’s no reason that such a system to take up more than a few hundred lines of code.
The question of proprietary code is a little more challenging since the developer does not want the source code to make it’s way to the end-users system at all. In this case I suggest one of two possibilities: 1) it may be possible to use encryption to prevent end-users from gaining access to the source, or 2) use an intermediary service that builds a package on a replica of the end users machine, turning over only the final results. Yes, this means complications for proprietary vendors, but it’s one that could easily be turned into a service.
The chore of the developer could then be greatly reduced to following a set of standards for organizing a project, providing metadata and optionally a build script for handling advanced build requirements. The target platform can take these pieces and build and install the package as is suitable to the platform. In other words, the platform takes care of the platform distinctions, not the developer.