Re: Quilt and patches directory
* Michael Biebl <biebl@debian.org> [080915 02:50]:
> > Because patch is a phony target which is therefore always out of date, and
> > therefore anything that depends on patch will be triggered to run every
> > time that you run debian/rules. Depending on patch instead of
> > $(QUILT_STAMPFN) can therefore cause odd behavior like running configure
> > twice or make twice, depending on the rest of debian/rules.
> >
>
> Could you give a real-world example when that can happen. I've always
> used the patch target (instead of $(QUILT_STAMPFN)) in my debian/rules
> files and so far haven't encountered any issues.
Actually, I think the "depending on the rest of debian/rules" is
incorrect, depending on "patch" always causes multiple invocations, not
only sometimes.
So to see the effects just take a lock at any build log of such a
package:
First look for debian/rules invocations. The important ones are build
and binary-arch. In the first there is configure and make invocation.
in the second there should usually (because of build*-patch) only be
one make install invocation and not extra make or configure invocation.
I you depend in patch instead of the stampfn there will be.
> Given that patch depends on $(QUILT_STAMPFN) I can't imagine a scenario
> where I would run into problems using the patch target.
It causes build (and perhaps configure) to be run a second time in the
binary target. That usually is usually not a real problem but only wasted
cycles of the build daemons, but it makes the process more fragile.
The binary target is usually run in fakeroot or other things, so that
configure run there another time might for example include fakeroot's
LD_PRELOAD or other things to places where you do not want it.
Looking around on your packages, most do not use patch directly. The
first I found that does (rsyslogd), has half of this problem and a
potential other problem:
| config.status: configure
|[...]
| build-stamp: patch config.status
This avoids the problem of runing configure again by telling make that
patch has not to be run before configure but in parallel (which usually
leads to it be run before, unless told to use multiple processors).
As you do not patch anything in the build system, that should not be an
problem here, though.
But make is run multiple times:
Take a look at
http://buildd.debian.org/fetch.cgi?&pkg=rsyslog&ver=3.18.2-1&arch=ia64&stamp=1218673256&file=log
In line 150 there is the first debian/rules build call, which calls make
in line 493.
In line 774 there is the debian/rules binary-arch call, which calls make
again in line 777 without need and touches build-stamp again in line 831
(as it does nothing in between, no harm is done but a few wasted buildd
time, having a build-stamp stamp file when it cannot be used because of
patch does not make much sense, though).
Hochachtungsvoll,
Bernhard R. Link
Reply to: