Re: debuild/dpkg-buildpackage behaves not as expected
debian-devel@liska.ath.cx (Olе Streicher) writes:
> Goswin von Brederlow <goswin-v-b@web.de> writes:
>> debian-devel@liska.ath.cx (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.
The state of the patches.
>>> 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
>> debuild
> [...]
>
> 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.
If the patches aren't rolled back to foo.patch after build then the
files will differ. If you still have the file open in an editor then
editing it will destroy stuf. And quilt refresh will refresh the topmost
patch and not foo.patch as intended.
So no, you can't do the same without the patch state being restored.
> The point is really: The state
> * compiled files (*.o etc.) from a patched package, but
> * unpatched source files
> is inconsistent.
In a good way. :)
> Best regards
>
> Ole
MfG
Goswin
Reply to: