[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#476100: devscripts: debuild should not fork dpkg-buildpackage



Hi,

On Mon, 2008-04-14 at 15:42 +0200, Raphael Hertzog wrote:
> while investigating #476054 I discovered that debuild is really a fork of
> dpkg-buildpackage and no more a simple wrapper of it. (BTW the manual
> page is wrong... it says "It first runs dpkg-buildpackage" which is not
> the case unless you have dpkg-cross installed... BTW dpkg-cross does no
> more divert dpkg-buildpackage in its latest versions).

I've just committed a set of patches to debuild:

+ Run dpkg-buildpackage directly where possible, rather than emulating it.
  Emulation will still be used if any of the clean, dpkg-source, build,
  binary, dpkg-genchanges or final-clean hooks are defined, as dpkg
  does not currently support them.

This should be fairly self-explanatory :-) I've verified that the pdksh
FTBFS is now reproducible using debuild.

+ Make it clearer that a particular invocation is using the emulated
  dpkg-buildpackage, and why.

A warning is printed reading:

debuild: emulating dpkg-buildpackage as the following hooks were defined:
  a, b, c

+ Automatically preserve the (C, CPP, CXX, LD and F)FLAGS variables and
  the corresponding *FLAGS_EXTEND variables
+ Add *FLAGS and *FLAGS_EXTEND support to the emulated dpkg-buildpackage

Again, hopefully self-explanatory. Both of these have been tested using
the filters FTBFS referred to in #475979 and #476138.

+ When running dpkg-buildpackage directly, pass through unrecognised
  options (with a warning) rather than aborting the build ourselves

The theory behind this change is that if dpkg-buildpackage acquires new
command line switches that debuild isn't aware of, then they can still
be used. If the option doesn't exist then the reporting of that issue
simply moves from debuild to dpkg-buildpackage.

At this point I'd like to suggest that we do one or more of the
following:
  a) close this bug in the 2.10.26 upload
  b) downgrade it
  c) block it against #476221

(I suspect some combination of b and c would be the least controversial :)

Regards,

Adam


Reply to: