10.1. Binaries

Two different packages must not install programs with different functionality but with the same filenames. (The case of two programs having the same functionality but different implementations is handled via “alternatives” or the “Conflicts” mechanism. See Maintainer Scripts and Conflicting binary packages - Conflicts respectively.) If this case happens, one of the programs must be renamed. The maintainers should report this to the debian-devel mailing list and try to find a consensus about which program will have to be renamed. If a consensus cannot be reached, both programs must be renamed.

To support merged-/usr systems, packages must not install files in both /path and /usr/path. For example, a package may not install both /bin/example and /usr/bin/example.

If a file is moved between /path and /usr/path in revisions of a Debian package, and a compatibility symlink at the old path is needed, the symlink must be managed in a way that will not break when /path and /usr/path are the same underlying directory due to symlinks or other mechanisms.

Binary executables must not be statically linked with the GNU C library, since this prevents the binary from benefiting from fixes and improvements to the C library without being rebuilt and complicates security updates. This requirement may be relaxed for binary executables whose intended purpose is to diagnose and fix the system in situations where the GNU C library may not be usable (such as system recovery shells or utilities like ldconfig) or for binary executables where the security benefits of static linking outweigh the drawbacks.

By default, when a package is being built, any binaries created should include debugging information, as well as being compiled with optimization. You should also turn on as many reasonable compilation warnings as possible (see Main building script: debian/rules). For the C programming language, this means the following compilation parameters should be used:

CC = gcc
CFLAGS = -O2 -g -Wall # sane warning options vary between programs
LDFLAGS = # none

By default all installed binaries should be stripped by calling

strip --strip-unneeded --remove-section=.comment --remove-section=.note binaries

on the binaries after they have been copied into debian/tmp but before the tree is made into a package.

It is not recommended to strip binaries by passing the -s flag to install, because this fails to remove .comment and .note sections, and also prevents the automatic creation of dbgsym binary packages by tools like dh_strip.

Although binaries in the build tree should be compiled with debugging information by default, it can often be difficult to debug programs if they are also subjected to compiler optimization. For this reason, it is recommended to support the standardized environment variable DEB_BUILD_OPTIONS (see debian/rules and DEB_BUILD_OPTIONS). This variable can contain several flags to change how a package is compiled and built.

It is up to the package maintainer to decide what compilation options are best for the package. Certain binaries (such as computationally-intensive programs) will function better with certain flags (-O3, for example); feel free to use them. Please use good judgment here. Don’t use flags for the sake of it; only use them if there is good reason to do so. Feel free to override the upstream author’s ideas about which compilation options are best: they are often inappropriate for our environment.