Why patch distributed software?
I will not go over the story of the OpenSSL fiasco again. Let’s just say that a developer inserted a particular patch in Debian OpenSSL package that he shouldn’t have. The patch was flawed in ways subtile enough that it escaped review 2 years. Long story short, Debian was left in a rather immense accumulation of fecal matter.
This was bad and made a lot of people object to the fact that software are patched in Linux distributions. It is true that software developers usually are the best person to fix the bugs in their software. What is still true but perhaps less obvious, is that most software developers are not ready or able to work in close cooperation with distribution developers so that their software are perfectly packaged without bugs and in time for a distribution release.
Distribution developers need to patch software for various, good, reasons, to ensure the best quality software distribution to their users, in a timely fashion.
Today I will examine three different kind of patch and try to justify why Debian developers, or distribution developers in general, will develope them. What is very important to note is that Debian, and probably most other distributions, wants that the patch the developers produce are sent to the original developers in the software they are packaging. In the case of the Debian distribution, this is mandated by the Debian Policy Manual, in section 4.3. That way, the patch can be eventually integrated in a future release, and the patch removed for the package for that new release.
The lesser divergence from upstream, the better. The OpenSSL fiasco is certainly a proof of that.
Plain bugfixes
It is a frequent occurance that packages are patched to fix small software bug. It is often inconvenient for a software packager to wait for a new release each time a bug is reported in the software they are responsible of. In some case, that release may come after several months (years), during which the bug will stay unfixed, which may in some case make the package unusable.
Patches are often pulled from the development repository of the software, if they can be backported to the version currently in the distribution.
Debian developers will then patch software when they can, to the best of their knowledge. It is recommended that they consult with the maintainer of the software before uploading their change to the distribution.
Patch example
http://patch-tracking.debian.net/patch/series/view/nano/2.0.7-4/ja_help_freeze.patch
In the case of the nano package, the existance of the patch is documented in the changelog of the package.
Compiler fixes
Like all other package in the distribution, compilers evolve and are eventually upgraded. Debian usually test new compilers ahead of time so they can stamp out compilation bugs early.
In case compilation fails for a package with a new version of a compiler, Debian developers will sometimes prefer to patch the program instead of asking the upstream developer to build his program with a recent or possibly unreleased version of the a compiler. They will patch the program to make it work with the new compiler and transmit the patch to the original developers for their future use.
Patch example
http://patch-tracking.debian.net/patch/series/view/qtodo/0.1.2-5/20-gcc.dpatch
This patch adapts the program to a newer than the one that was probably used to develop the package.
FHS bugfixes
The Debian distribution try to closely follow the Filesystem Hierarchy Standard (FHS). This is actually mandated in the Debian Policy Manual, section 9.1 so, if a program puts a file in a wrong place, it is viewed as a important bug.
Fortunately, most developers will follow the FHS, by habit or consciously. This simplify the packaging process, most program won’t need to be changed to be compliant. Sometimes though, some developers consider that it is not improper that a global configuration file is put outside /etc, or that image files can be put in /var.
Patch example
http://patch-tracking.debian.net/patch/series/view/trac/0.10.3-1etch4/01_use_global_config
This patch tells the Trac web application to look for its configuration file in /etc instead of /usr/share.
That will be enough for today. I think I’m already beyond the “tl;dr” level for most people. I will try to find some more example of types of patch done by packagers in another blog post.
