Hi, On Thu, 29 Mar 2012, Wookey wrote: > Anyone know when this happened and what if any, the limitations are? > It's certainly true in wheezy, squeeze, precise and oineiric.
This has always been the case ever since dpkg-architecture has been introduced. But you should not rely on this because calling debian/rules directly must be supported. dpkg-buildpackage(1) clearly states: | Even if dpkg-buildpackage exports some variables, debian/rules should | not rely on their presence and should instead use the respective | interface to retrieve the needed values. And this interface is "dpkg-architecture" itself in this case. > Now, you can build packages without using dpkg-buildpackage by calling > rules directly, and in that case the rules file would need to call > dpkg-architecture, but someone would have to convince me that that was > an interface worth supporting for non-native builds, because I > have certainly always considered the minimal interface for cross > package-building to be dpkg-buildpackage -a<arch>, and in practice > there are other things you need to do for non-trivial packages (set > CONFIG_SITE, set DEB_BUILD_OPTS=nocheck). (and ensure various things > like toolchain and dpkg-cross are installed). And I don't think we want > that stuff in every single rules file. I don't see why you're differentiating non-native builds from native builds (unless you assume different debian/rules files). In any case, if you're worried about the boilerplate code required to get the variables defined, you can now use "include /usr/share/dpkg/architecture.mk" to avoid it (but this requires dpkg-dev >= 1.16.1). 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/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120329190625.ge9...@rivendell.home.ouaza.com
