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
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
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.