Chapter 4. Source packages
When specifying the set of build time dependencies, one should list only those packages ex
plicitly required by the build. It is not necessary to list packages which are required merely
because some other package in the list of build time dependencies depends on them.
If build time dependencies are specified, it must be possible to build the package and pro
duce working binaries on a system with only essential and build essential packages installed
and also those required to satisfy the build time relationships (including any implied relation
ships). In particular, this means that version clauses should be used rigorously in build time
relationships so that one cannot produce bad or inconsistently configured packages when the
relationships are properly satisfied.
`Declaring relationships between packages' on page
explains the technical details.
4.3 Changes to the upstream sources
If changes to the source code are made that are not specific to the needs of the Debian system,
they should be sent to the upstream authors in whatever form they prefer so as to be included
in the upstream version of the package.
If you need to configure the package differently for Debian or for Linux, and the upstream
source doesn't provide a way to do so, you should add such configuration facilities (for exam
ple, a new
) and send the patch to the upstream authors, with the
default set to the way they originally had it. You can then easily override the default in your
or wherever is appropriate.
You should make sure that the
utility detects the correct architecture specification
string (refer to `Architecture specification strings' on page
If you need to edit a
where GNU style
scripts are used, you should edit
files rather than editing the
directly. This allows the user to reconfigure the
package if necessary. You should not configure the package and edit the generated
This makes it impossible for someone else to later reconfigure the package without losing the
changes you made.
control that the policy documents do).
Having a separate package allows one to install the build essential packages on a machine, as well as allow
ing other packages such as tasks to require installation of the build essential packages using the depends
The separate package allows bug reports against the list to be categorized separately from the policy man
agement process in the BTS.
The reason for this is that dependencies change, and you should list all those packages, and only those
packages that you need directly. What others need is their business. For example, if you only link against
, you will need to build depend on
but not against any
currently depends on them: installation of
will automatically ensure
that all of its run time dependencies are satisfied.