Re: debuild/dpkg-buildpackage behaves not as expected
debian-devel@liska.ath.cx (Olе Streicher) writes:
> James McCoy <vega.james@gmail.com> writes:
>> On Wed, May 16, 2012 at 04:23:05PM +0200, Olе Streicher wrote:
>>> Unpatching the sources *before* the build process was cleaned up makes
>>> no sense to me at all. Could you provide a use case for that?
>> As was described in #649531:
>>
>> vcs clone <repository with unpatched source>
>> cd repo
>> ... tweak a little ...
>> dpkg-buildpackage; # applies patches, builds, and unapplies patches
>> vcs diff; # looks good?
>> vcs commit
>
> This works only for the special case that "build" does not change any
> source file. Otherwise you would also commit the changed source files.
And it better not. There is no excuse for changing source files during
build. If you need to change a file then that means that file isn't
source anymore but generated. Try switching to out-of-tree builds if you
have something like that.
> Since for Debian you have only changes in the debian/ subdirectory, you
> may do the following:
>
> vcs clone <repository with unpatched source>
> cd repo
> .... tweak a little ...
> dpkg-buildpackage; # applies patches, builds, and unapplies patches
> vcs diff debian
> vcs commit debian
>
> this does not require unpatching, since it commits only the "debian"
> subdirectory, which is not affected by any patches.
>
> Therefore, I don't see that the workflow you mentioned is a use case
> that would require unpatching.
>
> [Quoting restored: Goswin wrote]
>>>> What happens if you now call
>>>> debuild patch
>>>> to apply the patches in a 3.0 (quilt) package that has patch/unpatch
>>>> targets?
>
>>> because it does *not* leave the sources in the same state.
>
>> Yes, it does.
>
> He wrote it himself: "patch" was meant as a target that *applies* the
> patches. Therefore, it does not leave the sources in the same state
> (since it applies the patches).
I ment: It leaves the source in the same state it found it other than
the side effects the called target(s) have themself.
>> If you started with patches applied, then they will still be applied
>> after calling "dpkg-buildpackage". If you didn't have patches
>> applied, then "dpkg-buildpackage" will apply the patches, build and
>> unapply the patches.
>
> We discussed the "debuild patch" option here which was introduced by
> Goswin.
>
> Best
>
> Ole
My main point, which I didn't explicitly state, is this:
The way debuild/dpkg-buildpackage/dpkg-source currently behave allow
maintainers to modify the behaviour by adding something to
debian/rules. If the clean target needs the patches applied then
debian/rules can easily make sure that they are.
On the other hand if the clean target doesn't need the patches applied,
as is the case for 99.9% of all packages then applying them would be
wastefull.
Personaly I try to set up all my packages in such a way that clean or no
clean I can simply commit changes. That means that the build MUST not
modify any source files (which is simply evil to begin with) and that
you add a bunch of stuff to the ignore file (e.g. debian/files,
debian/<pkg>/, debian/*.debhelper.log, debian/*.substvars, stamp files,
...). That is something you do once and after that clean or no clean you
can simply commit. But that requires that patches are unapplied after
build (unapply-patches in debian/source/local-options to enforce
this). I usualy never call clean directly so the above problem can't
even arise.
MfG
Goswin
Reply to: