Re: dpkg-buildpackage now sets DEB_BUILD_HOST etc for you?
On Thu, 29 Mar 2012, Wookey wrote:
> > But you should not rely on this because calling debian/rules directly
> > must be supported.
>
> Hmm, but if a package cannot use the variables set by
> dpkg-buildpackage and must set them itself, what is the point of
> dpkg-buildpackage setting them? To save the package exporting the
> variables?
I see two main reasons (but I did not write the original code, so I don't
know the initial motivation):
1/ this allows debian/rules to use "?=" assignation resulting in no-op
when the variables are set. This avoids multiple dpkg-architecture
invocations since dpkg-buildpackage only calls it once.
2/ it is required for cross-compilation since the fact that DEB_HOST_ARCH
is set to a value that is not equal to DEB_BUILD_ARCH is the canonical
fact that defines cross-compilation of the debian package
> Well, perhaps I shouldn't (and indeed I'd like us to get to a point
> where we don't), but currently, in practice, non-native builds need
> other things setting in the environment anyway so even using
> dpkg-buildpackage isn't necessarily sufficient, whereas for a native
> build it always is.
OK but this should ideally be integrated in common layers such as
CDBS and debhelper.
> Now if everyone is happy that debian/rules remains the canonical
> interface even for cross-builds and that they should work without
> dpkg-buildpackage help then I should start testing on that basis. I
> have not done that to date.
Honestly I have never seen anyone doing cross-builds and calling
debian/rules manually. So while I believe that cross-build should
not make different assumptions from native builds (i.e. we want to
converge), I would also not bother testing this explicitly.
"dpkg-buildpackage -a" is what people are using (and should be using).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
Reply to: