Debian buildd have always used dpkg-buildpackage to build Debian packages but this tool largely relies on debian/rules. Only 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 might 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: have the debian/rules caller setup the standard build environment
We modify Debian policy so that debian/rules files can rely on the set of environment variables exported by dpkg-buildpackage (the list can be hardcoded, it won't evolve much over time). Calling debian/rules directly is still possible but it doesn't guaranty that the result will be the same as a package built with the various environment variables set to the default value chosen by their respective distributions (those are exported by dpkg-buildpackage). To avoid the difference, people can use dpkg-buildpackage --target target instead of debian/rules target (a debian-rules wrapper script can be created to further ease the conversion if needed).
Advantages
Many rules files can be simplified and shortened by removing the logic that is already present in dpkg-bp (examples: put -O0 or -O2 in CFLAGS depending on the presence of noopt in DEB_BUILD_OPTIONS, or using DEB_HOST_ARCH without querying dpkg-architecture).
- 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]).
In a default sudo configuration, dpkg-buildpackage -rsudo does not do what's needed since environment variables set by dpkg-buildpackage are not always forwarded to the rules file because sudo strips them (for the targets where root rights are needed).
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. We can mitigate this by requiring that all packages include a Makefile snippet provided by dpkg-dev (ex: include /usr/share/dpkg-dev/setup-env.mk).
- But then, why not rely on dpkg-buildpackage directly? it would avoid the need to modify all packages. Here we come back to the comparison between the two choices here. --Raphael Hertzog