A good reason to keep patched source in $VCS

There are a lot of different workflows to maintain Debian packages under a Version Control System. Some people prefer to only keep the debian directory, some the whole source. And in the latter category, some prefer the source tree to be patched with Debian changes, while others prefer to keep it unpatched and exclusively use debian/patches.

It turns out the former and the latter don't work so well in one specific case that any package may hit some day ; and that day, you realize how wrong you were not tracking the entire patched source. That happened to me recently, though instead of actually going forward and switch to tracking the patched source, I cheated and simply ditched the patch, because I didn't strictly need it.

In all fairness, this is not only a case against not tracking patched source, but also a case of the 3.0 (quilt) source format being cumbersome.

In my specific case, I cherry picked an upstream patch modifying and adding some test cases related to a cherry-picked fix. One of the added test cases was a UTF-16 file. UTF-16 files can't be diff'ed nor patch'ed except in the git patch format, but quilt doesn't use nor support that. The solution around this limitation of 3.0 (quilt) format is to include the plain modified file in the Debian tarball, and add its path to debian/source/include-binaries.

On the VCS side of things, it means you have to modify the file in the source directory, and fill debian/source/include-binaries accordingly. Wait. Modify the file in the source directory ? But the other files aren't ! They're tracked by patches !

So here you are, with all of your modifications exclusively in debian/patches... except one.

2011-03-06 10:27:33+0900

debian

You can leave a response, or trackback from your own site.

5 Responses to “A good reason to keep patched source in $VCS”

  1. Jonathan Nieder Says:

    And here I was, thinking you were about to point out how constantly patching and unpatching file fights make(1). :)

  2. glandium Says:

    I actually never build in the VCS work directory, so that’s never been a problem for me.

  3. Np237 Says:

    The biggest problem with managing the patched source is that the resulting Debian source package is unusable. There are ways to generate a correct source, like topgit, but it is very cumbersome.

  4. Charles Plessy Says:

    I am a bit surprised that diff can not produce a patch for a UTF-16 file. In one of my packages I have encountered an upstream patch that adds a GIF file and modifies a jar file, and quilt applied it correctly:

    http://git.debian.org/?p=debian-med/emboss.git;a=blob;f=debian/patches/official-upstream-patch.patch;hb=74532119e054c9b1f400c60299323d583de93732

  5. Dave Walker Says:

    Yes! It’s crazy that you /have/ to edit upstream source to bundle a new binary, but patches *have* to be in debian/patches with 3.0 (quilt). I’d love include-binaries to be allowed to be a directory, and include a mirrored tree of where the file is.

Leave a Reply