Package: dpkg-dev Version: 1.16.3 Severity: important If I untar the orig.tar.gz by hand, then copy the debian/* files and then invoke dpkg-buildpackage, dpkg-buildpackage realizes that the patches need to be applied first, so it applies them and then the package is built. This is ok so far.
The problem is that at the same time, dpkg-buildpackage seems to unapply the patches *after* building the package, when the source tree is full of executables, objects, Makefiles and so on. This is when a disaster might happen, as some of the patches might be required so that the clean target works properly. As a result, building the package twice in a row by invoking dpkg-buildpackage twice fails. So, IMHO, one of the following things should be done: * The feature of applying the patches automatically when they are detected not to be applied yet is removed completely, as it is not well supported. * dpkg-buildpackage should not unapply the patches on a built tree, by doing so the tree might become un-cleanable. I discovered this while converting the recode package to dh. There is a huge patch which updates all the libtool stuff. If the patches are unapplied after the build, make distclean tries to recreate the Makefiles by running "config.status --recheck", which in turn fails with this funny error: checking build system type... Invalid configuration `x86_64-linux-gnu': machine `x86_64' not recognized as config.sub and config.guess have been reverted back to the stone age (!). To summarize: IMHO, unapplying patches after the build is fundamentally wrong, the fact that they had to be applied before the build is not a reason good enough to unapply them after the build. Thanks. -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
