Building a Stronger Foundation for Linux

Recently, I wrote about the need for Linux operating system providers to expand the range of ready-to-install applications available for their distributions by pooling their software packaging efforts, perhaps with the help of Novell’s OpenSUSE Build Service project.

I was pleased to learn that the Linux Foundation, an industry consortium aimed at fostering the growth of the platform, announced plans to pair up with Novell to deliver just such an offering. The service, which the group outlined at its recent Collaboration Summit in San Francisco, will be available through the foundation’s Linux Developer Network, where it will aid in the creation of software packages for CentOS, Debian, Fedora, Mandriva, OpenSUSE, Red Hat Enterprise Linux, SUSE Linux Enterprise and Ubuntu.

The Build Service should fit well with the Linux Foundation’s other activities, in particular the development of the Linux Standard Base, a set of standards intended to ensure application binary compatibility across different Linux-based operating systems. The idea is that a stable ABI for Linux will save the platform from the incompatibility issues that challenged the family of Unix flavours during the heyday of that platform.

Through standards and compatibility testing tools, the LSB has worked behind the scenes to encourage a baseline of compatibility among Linux distributions for some time now, but significant gaps remain. For instance, papering over the differences between individual distributions’ package management systems remains, for the most part, out of the LSB’s scope. The LSB does mandate a particular package type, the RPM format used by Red Hat and Novell, but limits RPM to a subset of its capabilities that’s known to work with Debian-based systems, through the package conversion application alien.

This approach to packages means that applications can be LSB-compliant without supporting the package management system of your chosen distribution particularly well. By making it easier for developers to support multiple Linux distributions in their native package formats, the Build Service project could allow the Linux Foundation to forget about enforcing some lowest common denominator package format and train its attention more tightly on lower-level compatibility issues.

In fact, if this Build Service effort takes off, it will provide Linux distributions and developers with added incentive to address particular compatibility issues, by promoting these issues from niggling wrinkles in an industry specification to living bugs in a critical software system. The most potent specifications are expressed not only on paper, but in running code as well.

For instance, both Red Hat and Ubuntu make use of source packages, which may be compiled to create binary packages that will run on a particular architecture. Both formats contain, in a compressed archive, the original source code from the upstream software developer. Source RPM packages tend to compress these archives with bzip, although gzip may also be used. Debian’s source package tools, on the other hand, only grok gzip compression.

That’s why, if you’re setting out to build packages for Debian-based distributions using the OpenSUSE Build Service and using a source RPM as a starting point, you’ll run into this compression wrinkle, as I did in some recent tests of the service. Now, if you were to ask the relevant Debian project maintainers to address this sort of interpackage management compatibility wrinkle for the sake of an industry standard, it might be tough to persuade the maintainers to devote resources to smoothing out the specification. On the other hand, if the Linux Foundation’s Build Service project becomes a central tool for package creation on Linux, this issue would demand a higher priority.

Certainly, life might be easier if all Linux distributions used the same package format, but it’s this sort of diversity that makes Linux strong. So far, the Linux and open-source community has consistently come up with ways to maintain diversity while making things work. I hope to see other key Linux players such as Red Hat and Canonical join with Novell and the Linux Foundation to keep that streak running.