On Mon, 2017-01-09 at 17:33 +0000, Ian Jackson wrote: > All of this applying and unapplying of patches around build > operations is complete madness if you ask me - but I don't see a > better approach given the constraints. dgit sometimes ends up doing > this (and moans about it), which is even madder given that dgit has > git to help it out. To state the bleeding obvious, it arises because on day 1 Debian decided to do the builds in the original source tree, then tries to recover the original source at the end by running "debian/rules clean". When I moved from rpm's to deb over a decade ago, I was surprised by this. Rpm's create temp build directory, so the "debian/rules clean" step can be handled reliably 100% of the time by the rpm build tool. Debian insisting you write it creates extra work. But when in Rome do as the Romans do and all that. Later when I started to work on other peoples packages it became apparent that many of the Romans didn't bother with it. So the debian/rules binary; dpkg --install; test; debian/rules clean; fix; rinse and repeat cycle doesn't work at all for maybe 1/3 of packages, and another 1/3 occasionally fail when something goes wrong during the patch / build process. When it goes wrong your only option is "rm -r; dpkg-source -x; manually reapply your changes" which is tedious, error prone, and for me least conducive to losing a days work. It is indeed utter madness that over a decade later we still allow this work flow.
Attachment:
signature.asc
Description: This is a digitally signed message part