On Thu, Oct 29, 2009 at 11:57:30PM +0100, Guillaume Yziquel wrote: > As far as I see it, git-buildpackage does not go through to the > "build" target, and fails before. It seems to me that the "clean" > target is called first, rdevices.ml and r_devices.c are erased, and > then git complains that things do not look good. It doesn't seem to > be a "cannot build twice in a row"-type issue... since there's no > building going on...
Let me try again to explain the general rule, also Mehdi replied to this
specific case, while I was trying to pose a more general policy. The
general rule is: "fakeroot debian/rules clean", no matter in which
situation you call it, should bring your source tree in the same
condition it was when the debian source package was unpacked in the
first place. Full stop here.
In your case, this rule is violated, because that target cleans up files
that are in the source tree when you unpack its corresponding source
package. That should be the case. The rational is simple: you have no
guarantees that buildd (or anyone else trying to build your package)
will do "clean" before "binary". Having the above rule violated creates
different environments in which build: one if you have invoked clean
before building, one if you have note. That discrepancy *might* be a
cause for a build failure, even in this precise case of yours it might
not be an actual problem.
You should fix that, so that "clean" does not remove those files (or,
alternatively, you should ensure those files are not in the upstream
tarball).
As an additional advantage in fixing that, git-buildpackage will stop
complaining; take that as a reward :)
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
