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

- 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

Reply via email to