First results with OpenSuse Build Service

After I started playing around with the OpenSuse Build Service a bit today I got a first impression about difficulties and problems, but also about the possibilities.

It is working. I was able to build a rsibreak package for both OpenSuse and for Fedora. Both with a single spec file.
However, I did have to add several if-OpenSuse-then and if-Fedora-then checks. This was mainly due to different package namings (some build requires), different handling of desktop files (desktop-file-install or suse_update_desktop_file) and using different paths for the prefix: Fedora uses /usr, OpenSuse uses /opt/kde3.
But there is nothing which makes building impossible – indeed, it simply shows where the distributions should work together more closely because diversity doesn’t make much sense in that areas. A good point here: it looks like that OpenSuse will switch to /usr for KDE 4. Also, some problems can be solved by the intelligent usage of variables.

Having a look at another Linux build system can also help to learn new things – I wasn’t for example aware of a possible security problem in my spec files. I was given to know that it might influence Fedora also.

However, while I’m still toying around with a simple application others already used the Build Service for much larger projects in real life: Amilcar provides kdevelop packages for all supported distributions. Also, mrdocs uses OBS to provide Scribus packages for all supported rpm based distributions.

Also I was told in IRC that some people think about building KDE 4 packages for all distributions via the OBS.

So judging form the first look there is – of course, it is Alpha – lots of space for improvements and automatic tools for example to overcome the little differences of the distributions – but it already works in a successful way – and it is really fun to play with.

Building Fedora packages using the OpenSuse Build Service

The OpenSuse Build Service is capable of creating package repositories for various distributions. Although it is different to the Fedora build system it shows an interesting alternative to the “build here only” attempt most distributions have today.

Motivation

In a recent discussion I was encouraged to try the OpenSuse Build Service (OBS). In principal, the OBS is a build farm where you can not only create packages for OpenSuse distributions, but also for the enterprise distributions of Suse – and for Mandriva, Fedora and even Debian. The packages generated are provided in distribution native repositories. And its up to you if you create a new repository for each package or if you collect more packages in one repository.

The advantage is evident: current attempts of spreading software in the Linux software world are doomed. If you have enough money you have to pay people to create a set of packages, one for each larger distribution (think for example of Skype here). If you are popular enough you can hope that there are enough volunteers to include your package in each distribution (think for example of ktorrent here). So if you are not that popular, don’t have enough money or want to release a beta version or development snapshot the best is to port your app to Windows and release executable snapshots there – Linux is hostile to small applications, niche software and software development in this regard.

While OBS is not the best solution because it only works on a specific set of distributions, it can still make the life much easier for software developers. At one central place native packages – together with native repositories – are created. You can easily provide different version of your program, even development versions or daily snapshots as pre-compiled binaries. Additionally you avoid joining all the distributions just to deliver one simple packet.

Differences between the Fedora build system (which is the only one I know besides OBS now) and the OBS are for example that you can manage the entire build process in a web page – if you want. There is of course also a CLI and most experienced packagers will default to that, however people who don’t plan to dig too deep into packaging might prefer the web page. It might also be possible to add integrate context help and help scripts for beginners into the web page.

Of course this all is not without any effort: while OBS allows you to have one single spec file for several distributions it asks you to take care of. There are scriptlets you need to include in some cases, however rpm spec files are able to include such things and work with them.

How it looks like

Here are some screenshots of the web interface I used. The first shows the main window of your account.

This screenshot shows the project overview – think of a project as a directory or repository. At the beginning you have one project in your home directory on the build server:

The last screenshot deals with the package overview where you see all important information (files, build status, etc.):

As you can see I was able to build rsibreak at least for Fedora 7 without any problems – I now have my own repository for it.
Of course this was for testing purposes only – you should not use this rsibreak version instead of the one Fedora provides in the repositories (although the spec file is almost the same, and the packager is the same ).
But it is a pretty good prove that the OBS is indeed working.

The look into the crystal ball

The OBS could become a central place for distributing software in the FLOSS world: every software project could create the necessary binaries there for all bigger distributions. Of course you would have to trust them – but you have to anyway, since you are using their software. Also, since it is a central place it might be easier to help the projects to actually build their software.

Also, the OBS is available as free software – it can even be downloaded as a VMWare image. So also a proprietary software vendor could use the OBS to distribute software – he would just set up his own OBS and work with it.
In contrast to tools like CNR the ISVs would keep the control over the packages – and could deliver entire repositories.

Of course the quality of the packages would – in average – be below the quality of native packages which for example went through a review (as it happens in Fedora). However there are possibilities to keep the quality of a package with automated tests (rpmlint for example) above a certain level, and this level might be stable enough. You have to find a balance anyway between the quality of packaged software on one hand and the amount of software available at the other. And currently there is hardly any balance.

But this is all dreaming about the future – at the moment OBS is still in heavy development and the multi-distribution packaging is not ready for productive usage yet (afaik). However, it is certainly an interesting tool to play with. Also, it might already be an option for people to distribute development snapshots in case the packages themselves have no strange dependencies.
So it is definitely worth a look.

Thanks to Francis Giannaros for the links and the motivation behind this article!