openSUSE Build Service
Why you want packages instead of building software yourself
Open source projects often have more or less simple instructions to build their software. Sometimes this can be the right thing to use, but often you want a better integration into your system; for example init scripts, logrotate configs, config files, … Using packages also provides an easy way to get rid of the software again (some projects provide a “make uninstall”, but it often doesn’t work reliable).
Especially when your distribution already provides a package, and you just want a newer release than what your distribution provides, building it yourself leads to more problems:
- if you install it in the same place like the still installed package, you get an ugly mix of new and old files (the new install perhaps doesn’t provide all files the old package did); and if you decide to remove the package later (“i build it myself, don’t need the package anymore”), it obviously breaks.
- if you install it in a different place (/usr/local instead of /usr for example), you get funny path conflicts – /usr/local/bin isn’t always in your PATH, but if it is, it is probably before /usr/bin; so depending on the context you will either use the old or the new binaries (“i installed the new release, but it still misses the feature”).
- for (shared) libraries installing without a package is suicide, as you need the package manager to track dependencies (and conflicts).
So you basically shouldn’t install software without a package manager.
If your distribution already provides a package, updating the package to a newer release might be easy, the package systems often try to keep the original source and their modifications to it separated in some way, so you only have to check whether those modifications still work with the new release, and perhaps update the dependencies.
Why providing packages
isn’t wasn’t easy
Obviously building packages still isn’t easy for most users, so it is obvious that you want the upstream developers to provide packages for their latest releases (the maintainers of your distribution won’t have the time to track all the upstream projects, and perhaps your distribution doesn’t even provide a package at all).
But providing packages for many distributions is time-consuming; you need to build the package on every distribution, and therefore have to maintain a install of it somewhere (probably in a vm).
Often different releases of a distribution need different handling in the details, perhaps have different names for dependencies or the build software providing more or less features.
In debian, the core build helpers are dpkg-dev and debhelper. Many packages require now debhelper >= 8, but older releases only have older versions. So now you need to install a new debhelper, which in turn requires perl 5.10 – which isn’t available in ubuntu hardy (still LTS for server).
You probable see now why most open source projects either provide no packages or only packages for a small number of dists (probably the ones they are using on their own systems).
https://build.opensuse.org/ (OBS) – while the url might look like they only support openSUSE, they actually support building rpm and deb packages for many distributions.
From time to time we discussed the problem with the debhelper versions; i failed backporting it on launchpad some years ago. darix finally tried it and got debhelper 8.1.6~bpo60+1 packages for Ubuntu 9.10, 10.04, 10.10 and 11.04. They didn’t need any other dependencies, so it wasn’t that hard :)
Now i finally got the Ubuntu 8.04 (hardy, LTS server) backport for debhelper and dpgk (and po4a) working, with some more or less ugly hacks in debhelper to get it working with perl 5.8.
Now i can use the same source package for all debian distributions, and still use the features from the current debhelper (as many packages in debian do, so it is easy to update a debian package to a newer version and build it in OBS).
Configure a project to build packages for Ubuntu hardy with backported debhelper:
1 2 3 4 5 6
<repository name="xUbuntu_8.04"> <path project="Ubuntu:backport-overlay" repository="xUbuntu_8.04"/> <path project="Ubuntu:8.04" repository="standard"/> <arch>x86_64</arch> <arch>i586</arch> </repository>
Similar for other Ubuntu versions (you can omit the second path line, as is included by the overlay too)
You can see some examples of this in the server:http project; as the Ubuntu projects in OBS don’t include universe and multiverse packages, there are still some dependencies missing. But you could always just copy the source packages from ubuntu to the project and build them again (see home:stbuehler/lighttpd).
PS: You might ask now why i’m not using launchpad. As a matter of fact i did (my ppas are still available, but not updated anymore). launchpad sucks, as i had to upload different packages for the different releases; the changelog has to specifiy the target release. So i wrote a shell script that would build different source packages with the needed changelog entries and so on… this just sucks. And of course it only builds ubuntu packages – with OBS i have “all” packages in one place (“all” as in “all i care about”).