# 4. Source packages

A Debian source package contains the source material used to construct one or more binary packages. A source package consists of a `.dsc` file (see Debian source package control files -- .dsc), one or more compressed tar files, and possibly other files depending on the type and format of source package. Binary packages are contructed from the source package via a build process defined by `debian/rules` and other files in the `debian` directory of the unpacked source package.

Debian source packages are classified as native or non-native.

A native source package is one that does not distinguish between Debian packaging releases and upstream releases. A native source package contains a single tar file of source material, and the versioning does not have a Debian-specific component. Native packages are normally (but not exclusively) used for software that has no independent existence outside of Debian, such as software written specifically to be a Debian package.

A non-native source package separates the upstream release from the Debian packaging and any Debian-specific changes. The source in a non-native source package is divided into one or more upstream tar files plus a collection of Debian-specific files. (Depending on the format of the source package, those Debian-specific files may come in the form of another tar file or in the form of a compressed diff.) The version of a non-native package has an upstream component and a Debian component, and there may be multiple Debian package versions associated with a single upstream release version and sharing the same upstream source tar files.

Most source packages in Debian are non-native.

## 4.1. Standards conformance

Source packages should specify the most recent version number of this policy document with which your package complied when it was last updated.

The version is specified in the `Standards-Version` control field. The format of the `Standards-Version` field is described in Standards-Version.

For a package to have an old Standards-Version value is not itself a bug, however. It just means that no-one has yet reviewed the package with changes to the standards in mind.

When updating existing packaging, the Standards-Version must not be updated except after reviewing the changes between the old and the new versions of the standards and updating your package if necessary (the Upgrading checklist can help with this task).

A very old Standards-Version can mean that infelicities in the package are likely. It is recommended that each package be reviewed at least once per Debian release, so a Standards-Version older than the previous Debian release is indicative of work (if only review work) that needs doing.

## 4.2. Package relationships

Source packages should specify which binary packages they require to be installed or not to be installed in order to build correctly. For example, if building a package requires a certain compiler, then the compiler should be specified as a build-time dependency.

It is not necessary to explicitly specify build-time relationships on a minimal set of packages that are always needed to compile, link and put in a Debian package a standard "Hello World!" program written in C or C++. The required packages are called build-essential, and an informational list can be found in `/usr/share/doc/build-essential/list` (which is contained in the `build-essential` package). [1]

When specifying the set of build-time dependencies, one should list only those packages explicitly 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. [2]

If build-time dependencies are specified, it must be possible to build the package and produce 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 relationships). 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 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 example, a new `autoconf` test or `#define`) 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 `debian/rules` or wherever is appropriate.

You should make sure that the `configure` utility detects the correct architecture specification string (refer to Architecture specification strings for details).

If your package includes the scripts `config.sub` and `config.guess`, you should arrange for the versions provided by the package autotools-dev be used instead (see autotools-dev documentation for details how to achieve that). This ensures that these files can be updated distribution-wide at build time when introducing new architectures.

If you need to edit a `Makefile` where GNU-style `configure` scripts are used, you should edit the `.in` files rather than editing the `Makefile` directly. This allows the user to reconfigure the package if necessary. You should not configure the package and edit the generated `Makefile`! This makes it impossible for someone else to later reconfigure the package without losing the changes you made.

## 4.4. Debian changelog: `debian/changelog`

Every source package must include the Debian changelog file, `debian/changelog`. Changes in the Debian version of the package should be briefly explained in this file. [3] This includes modifications made in the Debian package compared to the upstream one as well as other changes and updates to the package. [4]

The format of the `debian/changelog` allows the package building tools to discover which version of the package is being built and find out other release-specific information.

That format is a series of entries like this:

    package (version) distribution(s); urgency=urgency
      [optional blank line(s), stripped]
      * change details
      more change details
      [blank line(s), included in output of dpkg-parsechangelog]
      * even more change details
      [optional blank line(s), stripped]
     -- maintainer name <email address>[two spaces]  date

`package` and `version` are the source package name and version number.

`distribution(s)` lists the distributions where this version should be installed when it is uploaded - it is copied to the `Distribution` field in the `.changes` file. See Distribution.

`urgency` is the value for the `Urgency` field in the `.changes` file for the upload (see Urgency). It is not possible to specify an urgency containing commas; commas are used to separate `keyword=value` settings in the `dpkg` changelog format (though there is currently only one useful keyword, `urgency`).

The change details may in fact be any series of lines starting with at least two spaces, but conventionally each change starts with an asterisk and a separating space and continuation lines are indented so as to bring them in line with the start of the text above. Blank lines may be used here to separate groups of changes, if desired.

If this upload resolves bugs recorded in the Bug Tracking System (BTS), they may be automatically closed on the inclusion of this package into the Debian archive by including the string: `closes: Bug#nnnnn` in the change details, where `#nnnnn` is the bug number. [5] This information is conveyed via the `Closes` field in the `.changes` file (see Closes).

The maintainer name and email address used in the changelog should be the details of the person who prepared this release of the package. They are not necessarily those of the uploader or usual package maintainer. [6] The information here will be copied to the `Changed-By` field in the `.changes` file (see Changed-By), and then later used to send an acknowledgement when the upload has been installed.

The date has the following format [7] (compatible and with the same semantics of RFC 2822 and RFC 5322):

    day-of-week, dd month yyyy hh:mm:ss +zzzz

where:

- `day-of-week` is one of: Mon, Tue, Wed, Thu, Fri, Sat, Sun

- `dd` is a one- or two-digit day of the month (01-31)

- `month` is one of: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec

- `yyyy` is the four-digit year (e.g. 2010)

- `hh` is the two-digit hour (00-23)

- `mm` is the two-digit minutes (00-59)

- `ss` is the two-digit seconds (00-60)

- `+zzzz` or `-zzzz` is the time zone offset from Coordinated

    Universal Time (UTC). "+" indicates that the time is ahead of (i.e., east of) UTC and "-" indicates that the time is behind (i.e., west of) UTC. The first two digits indicate the hour difference from UTC and the last two digits indicate the number of additional minutes difference from UTC. The last two digits must be in the range 00-59.

The first "title" line with the package name must start at the left hand margin. The "trailer" line with the maintainer and date details must be preceded by exactly one space. The maintainer details and the date must be separated by exactly two spaces.

The entire changelog must be encoded in UTF-8.

For more information on placement of the changelog files within binary packages, please see Changelog files and release notes.

## 4.5. Copyright: `debian/copyright`

Every package must be accompanied by a verbatim copy of its distribution license(s) in the file `/usr/share/doc/PACKAGE/copyright`.

This file is often required to contain a verbatim copy of the package's copyright information, too; see Copyright information and 著作権に関する考慮 for details, and for further considerations related to copyrights for packages.

## 4.6. Error trapping in makefiles

When `make` invokes a command in a makefile (including your package's upstream makefiles and `debian/rules`), it does so using `sh`. This means that `sh`'s usual bad error handling properties apply: if you include a miniature script as one of the commands in your makefile you'll find that if you don't do anything about it then errors are not detected and `make` will blithely continue after problems.

Every time you put more than one shell command (this includes using a loop) in a makefile command you must make sure that errors are trapped. For simple compound commands, such as changing directory and then running a program, using `&&` rather than semicolon as a command separator is sufficient. For more complex commands including most loops and conditionals you should include a separate `set -e` command at the start of every makefile command that's actually one of these miniature shell scripts.

## 4.7. Time Stamps

Maintainers should preserve the modification times of the upstream source files in a package, as far as is reasonably possible. [8]

## 4.8. Restrictions on objects in source packages

The source package must not contain device special files, sockets, or setuid or setgid files. [9]

## 4.9. Main building script: `debian/rules`

This file must be an executable makefile. It contains the package-specific recipes for compiling the source (if required) and constructing one or more binary packages.

`debian/rules` must start with the line `#!/usr/bin/make -f`, so that it can be invoked by saying its name rather than invoking `make` explicitly. That is, invoking either of `make -f debian/rules args...` or `./debian/rules args...` must result in identical behavior.

The recommended way to implement the build process of a Debian package, in the absence of a good reason to use a different approach, is the `dh` tool. This includes the contents of the `debian/rules` building script. `dh` is the most common packaging helper tool in Debian. Using it will usually save effort in complying with the rules in this document, because `dh` will automatically implement many of them without requiring explicit instructions.

There are sometimes good reasons to use a different approach. For example, the standard tools for packaging software written in some languages may use another tool; some rarer packaging patterns, such as multiple builds of the same software with different options, are easier to express with other tools; and a packager working on a different packaging helper might want to use their tool. The recommendation to use `dh` does not always apply, and use of `dh` is not required.

For more information about how to use `dh`, see the documentation in the debhelper package, most notably the dh(1) manual page.

The following targets are required and must be implemented by `debian/rules`: `clean`, `binary`, `binary-arch`, `binary-indep`, `build`, `build-arch` and `build-indep`. These are the targets called by `dpkg-buildpackage`.

Since an interactive `debian/rules` script makes it impossible to auto-compile that package and also makes it hard for other people to reproduce the same binary package, all required targets must be non-interactive. It also follows that any target that these targets depend on must also be non-interactive.

The package build should be as verbose as reasonably possible, except where the `terse` tag is included in `DEB_BUILD_OPTIONS` (see debian/rules and DEB_BUILD_OPTIONS). This makes life easier for porters and bug squashers more generally, who can look at build logs for possible problems. To accomplish this, `debian/rules` should pass to the commands it invokes options that cause them to produce verbose output. For example, the build target should pass `--disable-silent-rules` to any configure scripts. See also Binaries.

Except for packages in the non-free archive with the `Autobuild` control field unset or set to `no`, required targets must not attempt network access to other hosts. Only access via the loopback interface to services on the build host that have been started by the build is allowed.

Required targets must not attempt to write outside of the unpacked source package tree. There are two exceptions. Firstly, the binary targets may write the binary packages to the parent directory of the unpacked source package tree. Secondly, required targets may write to `/tmp`, `/var/tmp` and to the directory specified by the `TMPDIR` environment variable, but must not depend on the contents of any of these.

This restriction is intended to prevent source package builds creating and depending on state outside of themselves, thus affecting multiple independent rebuilds. In particular, the required targets must not attempt to write into `HOME`.

The targets are as follows:

`build` (required)

  The `build` target should perform all the configuration and compilation of the package. If a package has an interactive pre-build configuration routine, the Debian source package must either be built after this has taken place (so that the binary package can be built without rerunning the configuration) or the configuration routine modified to become non-interactive. (The latter is preferable if there are architecture-specific features detected by the configuration routine.)

  For some packages, notably ones where the same source tree is compiled in different ways to produce two binary packages, the `build` target does not make much sense. For these packages it is good enough to provide two (or more) targets (`build-a` and `build-b` or whatever) for each of the ways of building the package, and a `build` target that does nothing. The `binary` target will have to build the package in each of the possible ways and make the binary package out of each.

  The `build` target must not do anything that might require root privilege.

  The `build` target may need to run the `clean` target first - see below.

  When a package has a configuration and build routine which takes a long time, or when the makefiles are poorly designed, or when `build` needs to run `clean` first, it is a good idea to `touch build` when the build process is complete. This will ensure that if `debian/rules build` is run again it will not rebuild the whole program. [10]

`build-arch` (required), `build-indep` (required)

  The `build-arch` target must perform all the configuration and compilation required for producing all architecture-dependent binary packages (those packages for which the body of the `Architecture` field in `debian/control` is not `all`). Similarly, the `build-indep` target must perform all the configuration and compilation required for producing all architecture-independent binary packages (those packages for which the body of the `Architecture` field in `debian/control` is `all`). The `build` target should either depend on those targets or take the same actions as invoking those targets would perform. [11]

  The `build-arch` and `build-indep` targets must not do anything that might require root privilege.

`binary` (required), `binary-arch` (required), `binary-indep` (required)

  The `binary` target must be all that is necessary for the user to build the binary package(s) produced from this source package. It is split into two parts: `binary-arch` builds the binary packages which are specific to a particular architecture, and `binary-indep` builds those which are not.

  `binary` may be (and commonly is) a target with no commands which simply depends on `binary-arch` and `binary-indep`.

  Both `binary-*` targets should depend on the `build` target, or on the appropriate `build-arch` or `build-indep` target, so that the package is built if it has not been already. It should then create the relevant binary package(s), using `dpkg-gencontrol` to make their control files and `dpkg-deb` to build them and place them in the parent of the top level directory.

  Both the `binary-arch` and `binary-indep` targets must exist. If one of them has nothing to do (which will always be the case if the source generates only a single binary package, whether architecture-dependent or not), it must still exist and must always succeed.

  The `binary` targets may need to be invoked as root depending on the value of the Rules-Requires-Root field. [12]

`clean` (required)

  This must undo any effects that the `build` and `binary` targets may have had, except that it should leave alone any output files created in the parent directory by a run of a `binary` target.

  If a `build` file is touched at the end of the `build` target, as suggested above, it should be removed as the first action that `clean` performs, so that running `build` again after an interrupted `clean` doesn't think that everything is already done.

  The `clean` target may need to be invoked as root if `binary` has been invoked since the last `clean`, or if `build` has been invoked as root (since `build` may create directories, for example).

  The `clean` target cannot be used to remove files in the source tree that are not compatible with the DFSG. This is because the files would remain in the upstream tarball, and thus in the source package, so the source package would continue to violate DFSG. Instead, the upstream source should be repacked to remove those files.

`patch` (optional)

  This target performs whatever additional actions are required to make the source ready for editing (unpacking additional upstream archives, applying patches, etc.). It is recommended to be implemented for any package where `dpkg-source -x` does not result in source ready for additional modification. See Source package handling: debian/README.source.

The `build`, `binary` and `clean` targets must be invoked with the current directory being the package's top-level directory.

Additional targets may exist in `debian/rules`, either as published or undocumented interfaces or for the package's internal use.

The architectures we build on and build for are determined by `make` variables using the utility `dpkg-architecture`. You can determine the Debian architecture and the GNU style architecture specification string for the build architecture as well as for the host architecture. The build architecture is the architecture on which `debian/rules` is run and the package build is performed. The host architecture is the architecture on which the resulting package will be installed and run. The target architecture is the architecture of the packages that the compiler currently being built will generate. These are normally the same, but may be different in the case of cross-compilation (building packages for one architecture on machines of a different architecture), building a cross-compiler (a compiler package that will generate objects for one architecture, built on a machine of a different architecture) or a Canadian cross-compiler (a compiler that will generate objects for one architecture, built on a machine of a different architecture, that will run on yet a different architecture).

Here is a list of supported `make` variables:

- `DEB_*_ARCH` (the Debian architecture)

- `DEB_*_ARCH_CPU` (the Debian CPU name)

- `DEB_*_ARCH_BITS` (the Debian CPU pointer size in bits)

- `DEB_*_ARCH_ENDIAN` (the Debian CPU endianness)

- `DEB_*_ARCH_OS` (the Debian System name)

- `DEB_*_GNU_TYPE` (the GNU style architecture specification string)

- `DEB_*_GNU_CPU` (the CPU part of `DEB_*_GNU_TYPE`)

- `DEB_*_GNU_SYSTEM` (the System part of `DEB_*_GNU_TYPE`)

where `*` is either `BUILD` for specification of the build architecture, `HOST` for specification of the host architecture or `TARGET` for specification of the target architecture.

Backward compatibility can be provided in the rules file by setting the needed variables to suitable default values; please refer to the documentation of `dpkg-architecture` for details.

It is important to understand that the `DEB_*_ARCH` string only determines which Debian architecture we are building on or for. It should not be used to get the CPU or system information; the `DEB_*_ARCH_CPU` and `DEB_*_ARCH_OS` variables should be used for that. GNU style variables should generally only be used with upstream build systems.

The builder may set `DEB_RULES_REQUIRES_ROOT` environment variable when calling any of the mandatory targets as defined in Rules-Requires-Root. If the variable is not set, the package must behave as if it was set to `binary-targets`.

### 4.9.1. `debian/rules` and `DEB_BUILD_OPTIONS`

Supporting the standardized environment variable `DEB_BUILD_OPTIONS` is recommended. This variable can contain several flags to change how a package is compiled and built. Each flag must be in the form flag or flag=options. If multiple flags are given, they must be separated by whitespace. [13] flag must start with a lowercase letter (`a-z`) and consist only of lowercase letters, numbers (`0-9`), and the characters `-` and `_` (hyphen and underscore). options must not contain whitespace. The same tag should not be given multiple times with conflicting values. Package maintainers may assume that `DEB_BUILD_OPTIONS` will not contain conflicting tags.

The meaning of the following tags has been standardized:

`nocheck`

  This tag says to not run any build-time test suite provided by the package.

`nodoc`

  This tag says to skip any build steps that only generate package documentation. Files required by other sections of Debian Policy, such as copyright and changelog files, must still be generated and put in the package, but other generated documentation such as help2man-generated pages, Doxygen-generated API documentation, or info pages generated from Texinfo sources should be skipped if possible. This option does not change the set of binary packages generated by the source package, but documentation-only binary packages may be nearly empty when built with this option.

`noopt`

  The presence of this tag means that the package should be compiled with a minimum of optimization. For C programs, it is best to add `-O0` to `CFLAGS` (although this is usually the default). Some programs might fail to build or run at this level of optimization; it may be necessary to use `-O1`, for example.

`nostrip`

  This tag means that the debugging symbols should not be stripped from the binary during installation, so that debugging information may be included in the package.

`parallel=n`

  This tag means that the package should be built using up to `n` parallel processes if the package build system supports this. [14] If the package build system does not support parallel builds, this string must be ignored. If the package build system only supports a lower level of concurrency than n, the package should be built using as many parallel processes as the package build system supports. It is up to the package maintainer to decide whether the package build times are long enough and the package build system is robust enough to make supporting parallel builds worthwhile.

`terse`

  This tag means that the package build will be less verbose than default. For example, `debian/rules` might pass options to the package's configure script that cause the compiler to produce less output.

Unknown flags must be ignored by `debian/rules`.

The following makefile snippet is an example of how one may implement the build options; you will probably have to massage this example in order to make it work for your package.

    CFLAGS = -Wall -g
    INSTALL = install
    INSTALL_FILE    = $(INSTALL) -p    -o root -g root  -m  644
    INSTALL_PROGRAM = $(INSTALL) -p    -o root -g root  -m  755
    INSTALL_SCRIPT  = $(INSTALL) -p    -o root -g root  -m  755
    INSTALL_DIR     = $(INSTALL) -p -d -o root -g root  -m  755

    ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
        CFLAGS += -O0
    else
        CFLAGS += -O2
    endif
    ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
        INSTALL_PROGRAM += -s
    endif
    ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
        NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
        MAKEFLAGS += -j$(NUMJOBS)
    endif

    build:
            # ...
    ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
            # Code to run the package test suite.
    endif

### 4.9.2. `debian/rules` and `DEB_BUILD_PROFILES`

If the `DEB_BUILD_PROFILES` environment variable is defined during the build of a source package, it specifies which build profiles are enabled. Its value is a space-separated, unordered list of enabled build profile names. By default, no build profiles are enabled. The following build profiles are standard:

`nocheck`

  This profile extends the meaning of the `nocheck` tag in `DEB_BUILD_OPTIONS` and must not be enabled unless combined with that tag. In addition to disabling build-time testing, it allows skipping the installation of dependencies required for those tests during the build. Note that enabling the profile or the tag must not functionally change the emitted binary packages and also must not change the set of binary packages produced. If tests happen to be installed into a binary package, it is recommended to add the `noinsttest` build profile.

`noinsttest`

  This profile disables the emission of binary packages consisting entirely of automated tests, manual tests, example/demo programs, and test tools. Other packages must not functionally change when this profile is enabled. Note that in many cases, it is only possible to drop such dependencies used for building when enabling both the `noinsttest` and the `nocheck` build profile at the same time. Therefore such dependencies tend to be conditional to `<!nocheck> <!noinsttest>`.

Commonly used but non-standard build profiles can be found in the Build Profile Spec.

The following makefile snippet is an example of how to enable Python support for all builds except when the package is built with the `nopython` build profile active.

    ifneq ($(filter nopython,$(DEB_BUILD_PROFILES)),)
        # nopython build profile was activated -- disable python
        CONFIGURE_SWITCHES += --disable-python
    else
        CONFIGURE_SWITCHES += --enable-python
    endif

Alternatively, one may defer the evaluation of restriction formulas in general (including architecture restrictions) to `debhelper`.

    ifneq ($(filter foo,$(shell dh_listpackages)),)
        # foo is being built
        CONFIGURE_SWITCHES += --enable-foo
    else
        CONFIGURE_SWITCHES += --disable-foo
    endif

### 4.9.3. `debian/rules` and `Rules-Requires-Root`

Depending on the value of the Rules-Requires-Root field, the package builder (e.g. dpkg-buildpackage) may run the `debian/rules` target as an unprivileged user and provide a gain root command. This command allows the `debian/rules` target to run particular subcommands under (fake)root.

The gain root command is passed to the build script via the `DEB_GAIN_ROOT_CMD` environment variable. The contents of this variable is a space separated list, the first entry of which is the command, and the proceeding entries of which are arguments to the command. The gain root command must be available via PATH. The gain root command must not rely on shell features because it will not necessarily be invoked via a shell.

The gain root command must not run interactively, including prompting for any user input. It must be possible to prepend the gain root command to an existing command and its arguments, without needing to alter or quote the existing command and its arguments. Furthermore, the gain root command must preserve all environment variables without the caller having to explicitly request any preservation.

The following are examples of valid gain root commands (in syntax of sh), assuming the tools used are available and properly configured:

    # Command "sudo", with arguments "-nE" and "--"
    export DEB_GAIN_ROOT_CMD='sudo -nE --'
    # Command "fakeroot" with the single argument "--"
    export DEB_GAIN_ROOT_CMD='fakeroot --'

Examples of valid use of the gain root command:

    # sh-syntax (assumes set -e semantics for error handling)
    $DEB_GAIN_ROOT_CMD some-cmd --which-requires-root

    # perl
    my @cmd = ('some-cmd', '--which-requires-root');
    unshift(@cmd, split(' ', $ENV{DEB_GAIN_ROOT_CMD})) if $ENV{DEB_GAIN_ROOT_CMD};
    system(@cmd) == 0 or die("@cmd failed");

## 4.10. Variable substitutions: `debian/substvars`

When `dpkg-gencontrol` generates binary package control files (`DEBIAN/control`), it performs variable substitutions on its output just before writing it. Variable substitutions have the form `${variable}`. The optional file `debian/substvars` contains variable substitutions to be used; variables can also be set directly from `debian/rules` using the `-V` option to the source packaging commands, and certain predefined variables are also available.

The `debian/substvars` file is usually generated and modified dynamically by `debian/rules` targets, in which case it must be removed by the `clean` target.

See deb-substvars(5) for full details about source variable substitutions, including the format of `debian/substvars`.

## 4.11. Upstream source location: `debian/watch`

This is a configuration file for the `uscan` utility which defines how to automatically scan ftp or http sites for newly available updates of the package. This is also used by some Debian QA tools to help with quality control and maintenance of the distribution as a whole. If the upstream source of the package is available via a mechaism that `uscan` understands, including this configuration file is recommended.

If the upstream maintainer of the software provides OpenPGP signatures for new releases, including the information required for `uscan` to verify signatures for new upstream releases is also recommended. To do this, use the `pgpsigurlmangle` option in `debian/watch` to specify the location of the upstream signature, and include the key or keys used to sign upstream releases in the Debian source package as `debian/upstream/signing-key.asc`.

For more information about `uscan` and these options, including how to generate the file containing upstream signing keys, see uscan(1).

## 4.12. Generated files list: `debian/files`

This file is not a permanent part of the source tree; it is used while building packages to record which files are being generated. `dpkg-genchanges` uses it when it generates a `.changes` file.

It should not exist in a shipped source package, and so it (and any backup files or temporary files such as `files.new`) [15] should be removed by the `clean` target. It may also be wise to ensure a fresh start by emptying or removing it at the start of the `binary` target.

When `dpkg-gencontrol` is run for a binary package, it adds an entry to `debian/files` for the `.deb` file that will be created when `dpkg-deb --build` is run for that binary package. So for most packages all that needs to be done with this file is to delete it in the `clean` target.

If a package upload includes files besides the source package and any binary packages whose control files were made with `dpkg-gencontrol` then they should be placed in the parent of the package's top-level directory and `dpkg-distaddfile` should be called to add the file to the list in `debian/files`.

## 4.13. Embedded code copies

Some software packages include in their distribution convenience copies of code from other software packages, generally so that users compiling from source don't have to download multiple packages. Debian packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way. [16] If the included code is already in the Debian archive in the form of a library, the Debian packaging should ensure that binary packages reference the libraries already in Debian and the convenience copy is not used. If the included code is not already in Debian, it should be packaged separately as a prerequisite if possible. [17]

## 4.14. Source package handling: `debian/README.source`

If running `dpkg-source -x` on a source package doesn't produce the source of the package, ready for editing, and allow one to make changes and run `dpkg-buildpackage` to produce a modified package without taking any additional steps, creating a `debian/README.source` documentation file is recommended. This file should explain how to do all of the following:

1. Generate the fully patched source, in a form ready for editing, that would be built to create Debian packages. Doing this with a `patch` target in `debian/rules` is recommended; see Main building script: debian/rules.

2. Modify the source and save those modifications so that they will be applied when building the package.

3. Remove source modifications that are currently being applied when building the package.

4. Optionally, document what steps are necessary to upgrade the Debian source package to a new upstream version, if applicable.

This explanation should include specific commands and mention any additional required Debian packages. It should not assume familiarity with any specific Debian packaging system or patch management tools.

This explanation may refer to a documentation file installed by one of the package's build dependencies provided that the referenced documentation clearly explains these tasks and is not a general reference manual.

`debian/README.source` may also include any other information that would be helpful to someone modifying the source package. Even if the package doesn't fit the above description, maintainers are encouraged to document in a `debian/README.source` file any source package with a particularly complex or unintuitive source layout or build system (for example, a package that builds the same source multiple times to generate different binary packages).

## 4.15. Reproducibility

Packages should build reproducibly, which for the purposes of this document [18] means that given

- a version of a source package unpacked at a given path;

- a set of versions of installed build dependencies;

- a set of environment variable values;

- a build architecture; and

- a host architecture,

repeatedly building the source package for the build architecture on any machine of the host architecture with those versions of the build dependencies installed and exactly those environment variable values set will produce bit-for-bit identical binary packages.

It is recommended that packages produce bit-for-bit identical binaries even if most environment variables and build paths are varied. It is intended for this stricter standard to replace the above when it is easier for packages to meet it.

## 4.16. Missing sources: `debian/missing-sources`

Sometimes upstream does not include the source code for some files in the upstream tarball. In order to satisfy the DFSG for packages in `main` or `contrib`, you should either:

1. repack the upstream tarball to include those sources; or

2. include a copy of the sources in the `debian/missing-sources` directory.

Package maintainers may optionally use the following convention to organize the contents of `debian/missing-sources`: for a sourceless file `foo` in the subdirectory `bar` of the upstream tarball, where the source of `foo` has extension `baz`, place the source at `debian/missing-sources/bar/foo.baz`. For example, according to this convention, the C source code of an executable `checksum/util` would be located at `debian/missing-sources/checksum/util.c`.

## 4.17. Vendor-specific patch series

Packages in the Debian archive using the 3.0 (quilt) source package format must not contain a non-default series file. That is, there must not exist a file `debian/patches/foo.series` for any `foo`.

[1]

Rationale:

- This allows maintaining the list separately from the policy documents (the list does not need the kind of control that the policy documents do).

- Having a separate package allows one to install the build-essential packages on a machine, as well as allowing other packages such as tasks to require installation of the build-essential packages using the depends relation.

- The separate package allows bug reports against the list to be categorized separately from the policy management process in the BTS.

[2]

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 `libimlib`, you will need to build-depend on libimlib2-dev but not against any `libjpeg*` packages, even though `libimlib2-dev` currently depends on them: installation of libimlib2-dev will automatically ensure that all of its run-time dependencies are satisfied.

[3]

Mistakes in changelogs are usually best rectified by making a new changelog entry rather than "rewriting history" by editing old changelog entries.

[4]

Although there is nothing stopping an author who is also the Debian maintainer from using this changelog for all their changes, it will have to be renamed if the Debian and upstream maintainers become different people. In such a case, however, it might be better to maintain the package as a non-native package.

[5]

To be precise, the string should match the following Perl regular expression:

    /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i

That is: The string should consist of the word `closes:` followed by a comma-separated list of bug numbers. Bug numbers may be preceded by the word `bug` and/or a `#` sign, as in `Closes: 42, bug#43, #44, bug 45`.

The list of bug numbers may span multiple lines.

All of the bug numbers listed will be closed by the archive maintenance software (`dak`) using the version of the changelog entry.

The words `closes:` and `bug` are not case sensitive.

[6]

In the case of a sponsored upload, the uploader signs the files, but the changelog maintainer name and address are those of the person who prepared this release. If the preparer of the release is not one of the usual maintainers of the package (as listed in the Maintainer or Uploaders control fields of the package), the first line of the changelog is conventionally used to explain why a non-maintainer is uploading the package. The Debian Developer's Reference (see 関連文書) documents the conventions used.

[7]

This is the same as the format generated by `date -R`.

[8]

The rationale is that there is some information conveyed by knowing the age of the file, for example, you could recognize that some documentation is very old by looking at the modification time, so it would be nice if the modification time of the upstream source would be preserved.

[9]

Setgid directories are allowed.

[10]

Another common way to do this is for `build` to depend on `build-stamp` and to do nothing else, and for the `build-stamp` target to do the building and to `touch build-stamp` on completion. This is especially useful if the build routine creates a file or directory called `build`; in such a case, `build` will need to be listed as a phony target (i.e., as a dependency of the `.PHONY` target). See the documentation of `make` for more information on phony targets.

[11]

This split allows binary-only builds to not install the dependencies required for the `build-indep` target and skip any resource-intensive build tasks that are only required when building architecture-independent binary packages.

[12]

The `fakeroot` package often allows one to build a package correctly even without being root.

[13]

Some packages support any delimiter, but whitespace is the easiest to parse inside a makefile and avoids ambiguity with flag values that contain commas.

[14]

Packages built with `make` can often implement this by passing the `-j`n option to `make`.

[15]

`files.new` is used as a temporary file by `dpkg-gencontrol` and `dpkg-distaddfile` - they write a new version of `files` here before renaming it, to avoid leaving a corrupted copy if an error occurs.

[16]

For example, parts of the GNU build system work like this.

[17]

Having multiple copies of the same code in Debian is inefficient, often creates either static linking or shared library conflicts, and, most importantly, increases the difficulty of handling security vulnerabilities in the duplicated code.

[18]

This is Debian's precisification of the reproducible-builds.org definition.