I'm thinking of filing a wishlist against dpkg over this, but I'd like to hear your opinion beforehand.
Basically, building the source of a 3.0 (quilt) package with dpkg-source -b will apply all patches to the source directory beforehand. This makes sense if you are managing your patches using quilt (in which case they are probably applied most of the time), but not so much when patches are worked on in separate branches (in which case they are never applied on the main branch). Every time I run dpkg-source -b, I have to do a quilt pop -a afterwards, and get rid of debian/patches/.dpkg-source-applied as well. Not to mention that if I left a file lying around for later uses (say, a TODO or log), it will be gobbled up in the debian-changes-version patch, and end up being deleted upon unpatching. (Now, I know that most *-buildpackage commands allow you to export the source to a temporary directory, but sometimes I prefer leaving a pbuilder chroot open and copying the source there manually, instead of launching a whole *-buildpackage each time.) So, I'm thinking of requesting an option to stop dpkg-source from messing around with my source directory. Two possible solutions come to mind: - Skip the application of patches (--no-preparation), and compare the source directory with the upstream, unpatched tarball(s). Either warn or abort if they differ (the diff may not apply on top of the other patches), with an option to keep going in the second case. - Copy the source directory to a temporary location, and apply the patches there. What do you all think? Am I making sense, or am I the only one driven nuts by this? :) -- ...Deep Hack Mode -- that mysterious and frightening state of consciousness where Mortal Users fear to tread. -- Matt Welsh _______________________________________________ vcs-pkg-discuss mailing list email@example.com http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss