Re: Feedback on 3.0 source format problems
On Sun, Jan 08, 2017 at 01:53:51AM +0100, Johannes Schauer wrote:
> Quoting Thibaut Paumard (2017-01-07 07:12:59)
> > I manage my patches using quilt. I would really prefer if sbuild et al.
> > would revert the patches after building by default, but that's life. I
> > respect that other people have other views.
>
> you could always file a wishlist bug against sbuild with your feature request.
> ;)
>
> I guess you are using sbuild from within an unpacked source package?
>
> The input for sbuild is always a source package. If all you give to sbuild is a
> directory, then it first needs to create that source package. It uses
> "dpkg-source -b ." for this purpose. It is dpkg-source which applies the
> patches.
>
> What you could already do today with sbuild is to say:
>
> sbuild --pre-build-commands="dpkg-source --after-build $(pwd)" ...
>
> You can also put this into your ~/.sbuildrc but that would then prevent you
> from using sbuild outside of unpacked source package directories.
>
> Sbuild could do this cleanup itself if there was a way to automatically
> determine whether the user would like their tree to be patches applied or
> unapplied. I do not even know of a way to determine upfront whether a source
> tree is patches applied or unapplied (that check has to be independent of the
> source format). Heck, with quilt, the source tree could even have patches half
> applied. I'm not so sure how fragile it will be to let sbuild try to put your
> source directory back into the state that it found it.
dpkg-source can almost do this for you; see later :)
> This also brings me to a question about the --unapply-patches option. The man
> page says:
>
> --no-unapply-patches, --unapply-patches
> By default, dpkg-source will automatically unapply the patches
> in the --after-build hook if it did apply them during
> --before-build (--unapply-patches since dpkg 1.15.8,
> --no-unapply-patches since dpkg 1.16.5). Those options allow
> you to forcefully disable or enable the patch unapplication
> process. Those options are only allowed in
> debian/source/local-options so that all generated source
> packages have the same behavior by default.
>
> Is --before-build not also run when using --build? That patches are applied
> when using --build indicates to me that it is.
No, it's not, but per dpkg-source(1) you can see that for 3.0 (quilt),
both --before-build and --build apply patches.
> But the --unapply-patches option
> seems to have no effect when used with --build. So is there a way to apply and
> unapply patches with a single dpkg-source call?
No, there isn't. The standard invocation by dpkg-buildpackage -S is:
dpkg-source --before-build .
fakeroot debian/rules clean
dpkg-source -b .
dpkg-source --after-build .
(also dpkg-gencontrol and dpkg-genbuildinfo)
> And if --unapply-patches does
> not have any effect together with --build, why do I not get a warning on the
> command line about this?
Wishlist bug against dpkg? :)
> And then there is the mysterious hint about
> debian/source/local-options which doesn't increase my understanding of the
> matter....
Indeed, but they seem to work when given on the command-line for
--after-build.
Now, if you look at the --(no-)unapply-patches description, you will see
> By default, dpkg-source will automatically unapply the patches in the
> --after-build hook if it did apply them during --before-build
This turns out to be true. Working in a patches-applied tree:
$ dpkg-source --before-build .
$ dpkg-source -b .
$ dpkg-source --after-build .
leaves the patches applied. Working in a patches-unapplied tree, the
patches are unapplied during the --after-build. This seems to do exactly
what you want, with the caveat that, if patches are only *part*-applied,
they will be completely unapplied by the --after-build, but this seems
like a very strange edge-case.
This behaviour is exactly what pdebuild has been doing forever (and
therefore git-buildpackage --git-pbuilder and others).
Regards,
James
Reply to: