The openSUSE Build System can be used to build binary packages for many versions of many Linux distributions without the need for you to have all these distributions installed.
At first I was somewhat skeptical about the openSUSE Build System (OBS) as a cross-Linux distribution build service. It does after all have the name of a Linux distribution in its project name so I assumed it was bound to have bias. The repositories offered as at July 2009 do reflect this to a degree, with openSUSE 10.3-11.1 and SUSE Linux Enterprise 9, 10, and 11 offered. However, alongside the enterprise SUSE offerings is Redhat Enterprise 4 and 5. To compliment the non enterprise SUSE offerings are Fedora 10 and 11, CentOS 5, Mandriva 2008 and 2009, as well as Ubuntu through 9.04.
If you see the above offerings as restrictive, you can download the OBS code and setup a build server of your own. So if you want to build packages for Fedora development "rawhide" Linux and SUSE/Novell decide not to support it you can always build those packages on a local or third-party OBS server.
The build system offers both a web and command line interface (osc). It is possible to create and build packages solely using the web interface. The command line client is required for more advanced interaction. To edit the files of a project, the osc command line tool uses commands very similar to revision control tools like cvs and subversion. When you commit a spec file or tarball the OBS will automatically trigger one or more package rebuilds for you.
The automatic build triggering is an extremely useful feature of OBS. If you are building for five target distribution-version combinations and have many packages in your build repository, OBS will work out what might need to be rebuilt whenever you check something in and schedule rebuilds accordingly. So if you have a tree of packages and you update one of the lower level projects, if it succeeds to build, any upper level projects that use it will also be rebuilt automatically.
There are a collection of rpm defines which are made available to the spec file when OBS builds a package. These can be used to change the way a build occurs for a particular distribution or version thereof. The spec file snippet shown below will perform an extra step if we are building on Fedora 10.
%if 0%{?fedora_version} == 10
%define LEGACY_FED 1
%endif
The first thought you might have when seeing these distribution and version specifying defines is to use them to smooth over differences in package names between different distributions. For example, the SigC++ signaling library can be packaged with a name of libsigc++2 or libsigc++20 depending on which distribution you are running. However, such direct work arounds for package name changes in your spec files are not needed. OBS maintains a mapping between the subtly different package names across distributions and fixes your spec file for you. When you think about it, it makes sense to offload this mapping into the build system itself rather than littering all of the spec files with such subtle package name mappings.
So when you are building with OBS you can simply state BuildRequires: libsigc++2-devel in your spec file and OBS will transform that package name to libsigc++20-devel if building against a Linux distribution which names the package in that manner. This is very handy for both preventing spec file bloat for users and sharing the knowledge of finicky subtle system package name changes for all users. When using OBS I noticed a few new package name mappings that were needed and the turn around from me reporting these to the OBS mailing list and them being implemented was usually about a day. Taking timezones into account this is quite fast.
To find out what these package mappings are, you can use the code shown below to checkout the metadata about Fedora 10 and 11 package name mappings. Other distribution names and versions can be used to find out their mappings. See the Substitute keyword which will map from an openSUSE package name to the package name that Fedora uses.
$ osc meta prjconf Fedora:10 >| f10-md.txt $ osc meta prjconf Fedora:11 >| f11-md.txt
When a package is built in OBS, the build host starts from the ground up. A very basic system is bootstrapped in a Xen virtual machine and you have to explicitly direct OBS to install any packages your software will need to build. This is not as ominous as it first seems, adding gcc-c++ and pkgconfig to your BuildRequires will get you started and then normally just adding a foo-devel for every foo that your software needs to build will get you close to building. However, having to explicitly BuildRequire the C++ compiler is a trap for the new OBS user.
The build logs can be viewed live from OBS. As the Xen machine progresses in the build the log is updated in your browser dynamically. This effectively gives you a tail -f for the build console in your browser. One current limitation is that config.log is not available for download if your ./configure script fails. A smart workaround is to have your spec file run configure with the below command, so if configure happens to fail, you get a copy of config.log in the normal build log from OBS.
%configure || cat config.log
To use OBS you have to create an account from the OBS homepage. Once you login you will automatically have a home project as home:username. You can build packages directly in your home project or create new subprojects to keep things logically separated.
In this series I'll package the SIP proxy/masquerading daemon project: siproxd. There are already packages for many Linux distributions for siproxd but not for Fedora 11. I'll assume that you already have some familiarity with creating spec files and assume some familiarity with deb packaging if you are intending to make those too.
Tune in next time when we'll concentrate on getting rpms to build for Fedora, then broaden things to include openSUSE and see and what changes are needed to the build setup. Creating deb files requires some additional steps which I'll leave for the final part of the series.
