The official interface to build debian packages has always been dpkg-buildpackage but this tool largely relies on debian/rules. The debian/rules interface is codified by the Debian Policy (see [http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules section 4.9]). The debian/rules interface is frequently used by developers to test some part of their rules file without doing a full build. However, by calling debian/rules directly, they miss some environment variables setup by dpkg-buildpackage. This could lead to (unexpected) difference of behaviors.
Environment variables setup by dpkg-buildpackage
All those exported by dpkg-architecture -a${targetarch} -t${targetgnusystem} -s -f. They are part of the environment since at least 2001 but the dpkg-architecture manual page and the Debian policy explicitely ask to not rely on them and to initialize the needed variables in debian/rules with dpkg-architecture -q.
CPPFLAGS, CFLAGS, CXXFLAGS, FFLAGS, LDFLAGS since 1.14.17 (Mar 2008). See [http://bugs.debian.org/465282 #465282] and https://wiki.ubuntu.com/DistCompilerFlags
DEB_VENDOR since 1.15.0 (to be uploaded). See [http://bugs.debian.org/457371 #457371], [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487437 #487437] and commit [http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=322153b6e8cbe50724f85678f46be5193a751a12 322153b].
What controls the build environment
During discussions, it appeared that having dpkg-buildpackage mess with the build environment is not always well accepted. Some people would rather let debian/rules handle everything and have dpkg-buildpackage stay out of the story. I tried to summarize below the advantages/disadvantages of each approach. Feel free to complete. -- RaphaelHertzog
Choice 1: accept that dpkg-bp defines the standard build environment
We accept that dpkg-bp plays a role in preparing the build environment and as such deprecate calling debian/rules directly. People have to call dpkg-buildpackage --target target instead of debian/rules target (a debian-rules wrapper script can be created to further ease the conversion). rules files can now rely on the variables exported by dpkg-buildpackage without having to define them themselves.
Advantages
- Many rules files can be simplified and shortened by removing the logic that is already present in dpkg-bp.
- For each distribution-wide change, we have the choice to make it opt-out (dpkg-bp imposes the change but the package can override it) or opt-in (dpkg-bp does nothing new, each package has to be updated separately).
- Centralized control of the basic build environment in a single place instead of multiple Makefile snippets that maintainers are going to use.
- Easier customization of built binaries (optimized builds, hardened builds) since dpkg-buildpackage provides a sane default for CFLAGS (and al.) that debian/rules does not have to redefine in most cases.
Disadvantages
- If dpkg-bp changes the way it setups the environment, some packages can be broken because the new environment variable or the new value has unexpected consequences. Depending on the case, this can be avoided by tying the change to a minimal Standards-Version, so that only package aware of the new requirement have the new variable/value.
You can't call debian/rules directly, you have to use dpkg-buildpackage --target (see [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477916 #477916] and commit [http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=66264bb2662d4f8d8cbe9e50c689182c4566a92d 66264bb]).
Choice 2: ensure that only debian/rules modifies the build environment
We don't accept that dpkg-bp plays a role in preparing the build environment and as such progressively remove the code that does so. Each rules files has full control on environment variables. If we want to try to standardize the build environment anyway, we have to provide a Makefile snippet and try to have as many packages as possible to use it.
Advantages
- Each package can rely on the fact that the build environment is stable and won't be modified if debian/rules itself is not modified.
debian/rules can be called directly.
Disadvantages
- For distribution-wide changes, only opt-in is possible as each package has to modify debian/rules to setup the environment as required.