Re: debuild/dpkg-buildpackage behaves not as expected
- To: email@example.com
- Subject: Re: debuild/dpkg-buildpackage behaves not as expected
- From: firstname.lastname@example.org (Olе Streicher)
- Date: Fri, 01 Jun 2012 13:23:02 +0200
- Message-id: <email@example.com>
- Reply-to: Ole Streicher <firstname.lastname@example.org>
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <20120516222552.GV12070@cerberus.jamessan.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
Goswin von Brederlow <firstname.lastname@example.org> writes:
> email@example.com (Ole Streicher) writes:
>> I think the best way would be that debuild/dpkg-buildpackage would not
>> automatically unapply the patches (so it would leave the source in the
> It doesn't automatically unapply the patches. It only restores the state
> you had before the dpkg-buildpackage was called.
It does not since it keeps the compiled files. If you mean it serious
with "restoring the state", you should call clean here, too.
>> or hook that does this for those who really need it (and know what they
>> are doing).
> Which would mean that you would have to unapply patches every time you
> try to build while working on a patch. With the current behaviour I can do
> quilt push foo.patch (foo.patch being somewhere in the middle)
> edit file
> quilt refresh
You can do the same even if either "clean" is called before the
unpatching was done, or if neither clean nor unpatching was done, since
quilt recognizes the state.
The point is really: The state
* compiled files (*.o etc.) from a patched package, but
* unpatched source files