This FAQ (frequently asked questions) was first published on the Ubuntu wiki. We thank Mark and his team for permission to republish it in Tectonic. Due to length, we have split the FAQ into multiple parts.

What about binary compatibility between distributions?
A lot has been said about the fact that Debian is not binary-compatible with Ubuntu. Sometimes this manifests itself as \”I can\’t install Ubuntu packages on Debian\”, sometimes its more \”Why does Ubuntu use GCC (Gnu Complier Collection) 4 when Debian is using GCC 3.3?\”. Or \”Why is the kernel and glibc on Ubuntu 5.04 different from that in Debian Sarge?\”. I\’ll try to address all of those here.

I\’ll start with our general policy and approach, and then examine some of those examples in detail.

First, \”binary compatibility\” means different things to different people. If you\’ve followed the trials and tribulations of the LSB (Linux Standards Base) standards process, you\’ll understand how difficult it is even to *define* binary compatibility in a meaningful way across multiple distributions. That, in essence, is why we don\’t set \”binary compatibility\” as a goal for Ubuntu. Sometimes it happens, but if so, it\’s accidental or because there was an opportunity to make something work nicely that someone took – not because it\’s a specific goal.

Just to be clear, I\’ll say it again, for the record. We don\’t aim for \”binary compatibility\” with any other distribution. Why?

In short, because we believe in Free Software as a collaborative process focused on SOURCE CODE, and consider it superior to the proprietary process which is focused on specific applications and binary bits. We choose to devote the large majority of our energy to the improvement of the source code that is widely and freely available, rather than trying to work on binary bits that cannot be shared as widely. When we spend hours of time on a feature, we want that work to be usable by as many other distributions as possible, so we publish the source code in \”real time\” as we publish new versions of the packages. We go to great lengths to make those patches widely available, in an easy to find format, so that they will be useful to upstreams, and other distributions. That benefits Debian, but it also benefits Suse and Redhat, if any of them are willing to take the time to study and apply the patches.

We synchronise our development with upstream, and with Debian, and with other distributions such as Suse and Gentoo and Mandrake and Redhat, on a regular basis. We draw code from the latest upstream projects (which might not even be in Debian, or in Redhat, or addressed in the LSB). We try to merge with Debian Unstable (a.k.a. Sid) every six months. We have no control over the release processes of other distributions, nor of upstream, so it would be impossible for us to define in advance an API (application program interface) or ABI (application binary interface) for each release. We are in the hands of hundreds of other developers every time we freeze Ubuntu in preparation for a new version. Even though the Ubuntu community is substantial and growing rapidly, it is still tiny compared to the total number of developers working on all the free software applications that make up the distribution itself. Our job is to package what is there, efficiently and cohesively, not to try to massage it to some pre-defined state of compatibility. We focus on delivering the newest-but-stabilised-and-polished versions of the best open source applications for your server or desktop. If we were to set binary compatibility (at any level) as a top priority, it would massively diminish our ability to deliver either newer software, or better integration and polish. And we think our users care most about the fact that they are getting the best, and most integrated, apps on the CD.

It is worth noting that the Linux kernel itself takes the same approach, shunning \”binary compatibility\” in favour of a \”custom monolithic kernel\”. Each release of the kernel requires that it be compiled separately from previous releases. Modules (drivers) need to be recompiled with the new release, they cannot just be used in their binary form. Linus has specifically stated that the monolithic kernel — based on source code, not trying to maintain a binary interface for drivers across releases — is better for the kernel. We believe the same is true for the distribution.

So the imperative to work with very current code overrides the idea of maintaining compatibility with a specific ABI, especially if we have little or no say in the ABI we should be trying to remain compatible with.