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
You can leave a response, or trackback from your own site.
2011-03-06 11:09:44+0900
And here I was, thinking you were about to point out how constantly patching and unpatching file fights make(1). :)
2011-03-06 12:19:53+0900
I actually never build in the VCS work directory, so that’s never been a problem for me.
2011-03-06 23:29:20+0900
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.
2011-03-07 01:29:07+0900
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
2011-03-14 09:35:02+0900
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.