(debian-policy.info)Binaries

---

Next: Libraries Up: Files<2>

---

Enter node , (file) or (file)node

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 Note: Maintainer
Scripts. and Note: 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 *note Main building script; debian/rules:
78.).  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 Note: 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.