Re: Quilt and patches directory
В Mon, 15 Sep 2008 21:28:54 +0200, Michael Biebl написа: I didn't know that foo: bar baz will result in bar/baz run in parallel. I thought there is some kind of guarantee that bar is processed first. Consider this example which illustrates that it's not a safe assumption to make always even with non-parallel make: cat makefile 'EOF' do-%: bar-% baz-% @true bar-%: @echo I am first! baz-foo: @echo I should be second. baz-frob: @echo Something else. EOF $ make do-foo I should be second. I am first! $ make -j2 do-foo I should be second. I am first! $ make do-frob Something else. I am first! When pattern rules come to the picture, and a pattern rule has prerequisites which exist or are explicitly mentioned like here, they always take precedence. You just have to be careful. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Quilt and patches directory
* Michael Biebl [EMAIL PROTECTED] [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=rsyslogver=3.18.2-1arch=ia64stamp=1218673256file=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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Quilt and patches directory
Andreas Schildbach wrote: Is there any way to tell quilt about the debian package structure? The way it works, it always looks in the current directory for the patches and .pc directories. What I'd like it to do is find the debian directory in the parent hierarchy and put/search for its patches directories there. IANADD I just operate within top level directory using relative path to all files. Quilt works well for me. Is it acceptable for you? -- Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer. signature.asc Description: OpenPGP digital signature
Re: Quilt and patches directory
On Sun, Sep 14, 2008 at 04:00:18PM +0200, Andreas Schildbach wrote: Is there any way to tell quilt about the debian package structure? The way it works, it always looks in the current directory for the patches and .pc directories. What I'd like it to do is find the debian directory in the parent hierarchy and put/search for its patches directories there. I've found http://chistera.yi.org/~adeodato/blog/104_quilt_options useful. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Quilt and patches directory
Le Sun, Sep 14, 2008 at 04:00:18PM +0200, Andreas Schildbach a écrit : Is there any way to tell quilt about the debian package structure? Hi Andreas, less /usr/share/doc/quilt/README.source Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Quilt and patches directory
On 2008-09-14, Raphael Geissert [EMAIL PROTECTED] wrote:
Russ Allbery wrote:
Raphael Geissert [EMAIL PROTECTED] writes:
if [ -e ${where}debian/rules -a -d ${where}debian/patches ]; then
export QUILT_PATCHES=debian/patches
Shouldn't it be
export QUILT_PATCHES=${where}debian/patches
?
No, quilt figures that part out for itself.
I don't understand the pourpose of the for where in ... then.
If you use quilt for patch management that isn't debian related.
/Sune
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
