Debian – Applying patches in debian packages – Part 2

Patches are usually contained in .diff files, because the patches are created using the diff command.

A patch is a series of insertions and deletions into source code. For this reason, in order to use the patch, you must build the application (e.g., "foobar") from source after applying the patch. So, in steps:

1. Get the source package for foobar.

Most linux distributions (n.b. patching is not unique to linux) have "source packages" you can use for this purpose, but since these are heterogeneous, I will only refer to the format of the original source here. The original source is not part of the distro and may be hard to find. A good place to start is wikipedia, which has articles for many popular applications, and the article should contain a link to a homepage with a source download. You can also google yourself, obviously. The source package will be called something like foobar.0.1.tar.bz2. Unpack this -- you now have a directory called foobar.0.1.

2. Add the patch.

Sometimes patches are single files and sometimes they are a set of several files. Copy those into foobar.0.1 and cd foobar.0.1. Next, you need to run the patch command. This reads from standard input, so you want to pipe the .diff file in. The tricky part is determining what to use for the -p option (if there are no instructions with the patch). To do that you need to look at the beginning of the patch file. For example:

--- old/comm.c  2003-09-08 14:25:08.000000000 +0000
+++ new/comm.c  2006-07-07 02:39:24.000000000 +0000

In this case, comm.c is the name of the source file that will be altered. However, notice that there is a directory appended to it. Since these are not the same directory ("old" vs. "new"), this is a big clue that this part of the path is junk (for our purposes). The purpose of the -p switch (see man patch) is to eliminate this prefix. It takes a number, which is the number of slashes (/) to eliminate, with everything in between; in this case we would use -p1 to reduce the path to just plain comm.c.

That presumes comm.c is actually in the same directory, which will be another clue as to whether your interpretation is correct. If both those lines were src/comm.c, and comm.c is actually in the src subdirectory of your build tree, then you need to use -p0 -- beware that not using -p at all will remove ALL slashes. If the path is absolute (i.e., begins with /), that's probably what you want. Now apply the patch:

patch -p1 < patch.diff

The source has now been modified. If there are more .diff files, apply those the same way.

3. Build and install.

This is the normal process you would go through to build something from source -- first ./configure, then make, make check, make install. Before you do the last one, if you already have an existing installation of foobar, decide whether you want to remove or overwrite that or how you are going to deal with the naming conflict. You probably want foobar to refer to your new, patched version, and not the old one.

This is not necessarily due to fuzz (in particular if you have refreshed the patches as told in the article). It may happen that the source has changed in such a way that patches are completely out of date. For instance, the original source was:

aa
bb
cc

and a patch told: replace line bb by dd (with some context, ignored here). Then the source changed to:

aa
bbb
cc

The patch still says: replace line bb by dd, but line bb no longer exists, so that the patch can no longer be applied successfully.

The solution is to look at the failed hunk, at the corresponding part of the old source (on which the patch could be applied), and try to see what has changed in the new source, then try to adapt the new source to regenerate the patch. This can only be done manually, and when there have been major changes in the source, this can be difficult, if not impossible.