Ian Murdock, of Debian fame, has written a nice summary of the recent LSB Packaging summit that explains what’s in the works when it comes to the future of Linux package management. It is very nice to see that there are good people working in this area, and I’m hopeful that in the future, third-party software installation in Linux will be a breeze.
As software developers targeting the Linux platform, this is of course a topic that concerns us very much. Here in the F-Secure Linux team, we as recently as today had some heated discussions about different ways to solve the packaging dilemma. We have several goals to fulfill, among them (in no particular order, and some of us may even disagree with some of these statements):
- we want our software to work on several different Linux distributions
- it should be reasonably manageable by system administrators
- from a building, testing and logistics perspective, it’s nice to have a small number of “end-products”, i.e. installer packages, produced by our build system
Currently, we’re shipping our products in a hybrid solution, trying to combine some of the benefits of a packaging system while being able to produce a single package “blob” of each build containing everything that is needed to install, configure and run the product. That package is a self-extracting executable installer that, by default, dumps a bunch of RPMs into a /tmp subdirectory, installs them, and then runs the configuration scripts needed to get the product up and running (it can also do some other magic, but that’s not important here). We are well aware that using RPM is not optimal for, for example, Debian-based distributions, but thanks to LSB, we can usually assume that the hurdles of installing RPM-based software aren’t too big. By supplying an “extract” argument to the installer executable, the operator can extract the raw RPM packages and install them manually, if need be (which is often a requirement to facilitate large installations of many hundreds or thousands of machines).
There is still much to be done, and we are surely keeping our eyes open in all directions when it comes to Linux package management - whether it be using alien to integrate more nicely with dpkg, moving to an autonomous package installer such as Autopackage or even any of the commercial packagers. I feel that while the solution we have now isn’t by any means optimal, it works pretty well and still gives the user some control. In the end, I want the installer to “just work” and fit right into whatever environment the user is using.