Dear Raphael and Mike, Thank you so much for explaining the reasons, I could mostly understand.
FWIW, your patch apply-debian-patches-at-build-time.patch does not work.
Actually, all patch files in debian/patches/* are applied correctly by debian/rules at the build-time when I execute the following commands. $ dpkg-source -x libxml2_2.7.8.dfsg-2+squeeze12.dsc $ cd libxml2-2.7.8.dfsg $ patch -p1 < /path/to/B_libxml2_apply-debian-patches-at-build-time.patch $ dpkg-buildpackage -rfakeroot In my understanding, the source format "1.0" doesn't have strict rules about applying patches to the upstream source tree. For example, binutils, pam, and some other "1.0" formatted packages also modify the upstream tree by both .diff and debian/patches/*. Therefore, I suggested applying individual patches with the patch "B", like the above packages. Anyway, as you say, the patch "B" should not be used if applying patches from debian/patches is not recommended for the source format "1.0". As another workaround, it might be good to use another directory name instead, for example debian/patches-applied. On 2015/07/03 21:14, Raphael Hertzog wrote:
Hi, On Fri, 03 Jul 2015, Mike Gabriel wrote:With later LTS work (wheezy, jessie, ...) we should have more and more "quilt (3.0)" format packages around in Debian, so this confusion will gradually reduce. I stumbled over this, as well, while preparing the libxml2 package, so I can understand you well. Do we have this procedure of shipping individual patch files in "1.0" formatted packages documented somewhere? Or is it documented in the Debian policy?To the best of my knowledge, no and no. Feel free to document this somewhere if you feel like it's useful. But given that 1.0 are disappearing rather quickly, I'm not going to invest much time in this. Cheers,