Jonathan Nieder wrote: Hi, > > On one hand, in dpkg's source format v3, the patched source is considered > to be standard "unpacked" form. So if you run > > dpkg-source -x foo.dsc > cd foo-* > dpkg-buildpackage; # just builds the package > > then patches will be applied in the first step and never unapplied.
Yes, but you know the object files created in the third step won't be dropped either. > This > is the way I like to work, for example (except that the source is stored > in a version control repository) --- the source with patches unapplied > just never enters into it. I've been using VCS to manage my packages for 10 years or so. I used to have some issues when switched some packages to quilt/dpatch/dbs a few years ago, but then I wrote some simple trigger that prevent me from committing sources with patches applied. Additionally I have my own debuild script which when called with clean argument calls real `debuild clean' + `quilt pop -a'. But anyway, reverting a broken commit takes a minute or so, recompiling package can take considerably more time. > > On the other hand, some people like to work most of the time with the > unpatched source, as in pre-v3 days. For them, dpkg-buildpackage is > happy to comply: > > vcs clone <repository with unpatched source> > cd repo > ... tweak a little ... > dpkg-buildpackage; # applies patches, builds, and unapplies patches And now you compare your package with older version (with debdiff) and discover than one file got installed in wrong location. You discover a typo in debian/rules... > vcs diff; # looks good? What if it doesn't look good? > > "dpkg-source --after-build" distinguishes between the two cases by > checking for the ".pc/.dpkg-source-unapply" file, I've noticed this file and already modified debian/rules to get rid of it. > applied. You can ensure patches remain applied by applying the > patches yourself before starting the build. > > QUILT_PATCHES=debian/patches quilt push -a > debuild; # or dpkg-buildpackage, or whatever Yes, I know. I can even modify my debuild script to do `quilt push -a', but it won't change the fact that unapplying patches automatically is just crazy idea. As I wrote in my previous mail, `debian/rules clean' should be called before unapplying patches. Actually it should be me, maintainer, who decides when and what to call. > Now I wouldn't be surprised if some edge cases are not handled in the > best way or some documentation is less clear than desirable. Pointers? Since --unapply-patches is now default, please add --no-unapply-patches. I wish I could set this option globally somewhere in /etc, so in case I need to do NMU of a random package I wouldn't waste my time on unnecessary recompilations. Thanks, robert -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
