The Linux Foundation and Novell team up to deliver Build Service, which will aid in the creation of software packages for CentOS, Debian, Fedora, Mandriva, OpenSUSE, Red Hat Enterprise Linux, SUSE Linux Enterprise and Ubuntu.
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 flavors 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.
As Editor in Chief of eWEEK Labs, Jason Brooks manages the Labs team and is responsible for eWEEK's print edition. Brooks joined eWEEK in 1999, and has covered wireless networking, office productivity suites, mobile devices, Windows, virtualization, and desktops and notebooks. Jason's coverage is currently focused on Linux and Unix operating systems, open-source software and licensing, cloud computing and Software as a Service. Follow Jason on Twitter at jasonbrooks, or reach him by email at jbrooks@eweek.com.
Email
Print
