Kapitel 6. Basics for packaging

# Kapitel 6. Basics for packaging

Here, a broad overview is presented without using VCS operations for the basic rules of Debian packaging focusing on the non-native Debian package in the „3.0 (quilt)“ format.

| Anmerkung
Zu Gunsten der Klarheit werden einige Details bewusst übergangen. Bitte lesen Sie die Handbuchseiten von dpkg-source(1), dpkg-buildpackage(1), dpkg(1), dpkg-deb(1), deb(5) usw.

Das Debian-Quellpaket ist eine Gruppe von Eingabedateien (d.h. nicht eine einzelne Datei), die zum Bau des Debian-Binärpakets verwandt werden.

Das Debian-Binärpaket ist eine besondere Archivdatei, die die Gruppe der installierbaren Binärdaten mit ihren zugehörigen Informationen enthält.

Ein einzelnes Debian-Quellpaket kann mehrere Debian-Binärpakete, die in der Datei debian/control definiert sind, installieren.

The non-native Debian package in the Debian source format „3.0 (quilt)“ is the most normal Debian source package format.

| Anmerkung
There are many wrapper scripts. Use them to streamline your workflow but make sure to understand the basics of their internals.

## 6.1. Arbeitsablauf des Paketierens

The Debian packaging workflow to create a Debian binary package involves generating several specifically named files (see „Abschnitt 6.3, „Paketname und -version““) as defined in the „Debian Policy Manual“. This workflow can be summarized in 10 steps with some over simplification as follows.

1. The upstream tarball is downloaded as the package-version.tar.xz file.
2. The upstream tarball is untarred to create many files under the package-version/ directory.

3. The upstream tarball is copied (or symlinked) to the particular filename packagename_version.orig.tar.xz.

   - the character separating package and version is changed from - (hyphen) to _ (underscore)
   - .orig is added in the file extension.

4. The Debian package specification files are added to the upstream source under the package-version/debian/ directory.

   - Required specification files under the debian/ directory:

     debian/rules
       Das ausführbare Skript zum Bau des Debian-Pakets (siehe „Abschnitt 6.5, „debian/rules file““)
     debian/control
       The package configuration file containing the source package name, the source build dependencies, the binary package name, the binary dependencies, etc. (see „Abschnitt 6.6, „debian/control file““)
     debian/changelog
       The Debian package history file defining the upstream package version and the Debian revision in its first line (see „Abschnitt 6.7, „debian/changelog file““)
     debian/copyright
       The copyright and license summary (see „Abschnitt 6.8, „debian/copyright file““)
     debian/source/format
       This indicates the desired format to dpkg-source(1) (see Debian wiki: „DebSrc3.0“)
   - Optional specification files under the debian/* (see „Abschnitt 6.14, „Other debian/* files““):
   - These files must be manually edited to their perfection according to the „Debian Policy Manual“ and „Debian Developer’s Reference“.

5. The dpkg-buildpackage command (usually from its wrapper debuild or sbuild) is invoked in the package-version/ directory to make the Debian source and binary packages by invoking the debian/rules script.

   - The current directory is set as: „CURDIR=/path/to/package-version/“

   - Create the Debian source package in the Debian source format „3.0 (quilt)“ using dpkg-source(1)

     - package_version.orig.tar.xz (copy or symlink of package-version.tar.xz)
     - package_version-revision.debian.tar.xz (tarball of debian/ found in package-version/)
     - package_version-revision.dsc

   - Build the source using „debian/rules build“ into $(DESTDIR)

     - „DESTDIR=debian/binarypackage/“ for single binary package [11]
     - „DESTDIR=debian/tmp/“ for multi binary package

   - Create the Debian binary package using dpkg-deb(1), dpkg-genbuildinfo(1), and dpkg-genchanges(1).

     - binarypackage_version-revision_arch.deb
     - …​ (There may be multiple Debian binary package files.)
     - package_version-revision_arch.changes
     - package_version-revision_arch.buildinfo

6. Check the quality of the Debian package with the lintian command. (recommended)

   - Follow the rejection guidelines from ftp-master.

     - „REJECT-FAQ“
     - „NEW-Checkliste“
     - „Lintian Autorejects“ („lintian tag list“)
7. Test the goodness of the generated Debian binary package manually by installing it and running its programs.
8. After confirming the goodness, prepare files for the normal source-only upload to the Debian archive.

9. Sign the Debian package file with the debsign command using your private openPGP key.

   - Use „debsign package_version-revision_source.changes“ (source-only upload situation)
   - Use „debsign package_version-revision_arch.changes“ (source+binary upload situation)

10. Upload the set of the Debian package files with the dput command to the Debian archive.

    - Use „dput package_version-revision_source.changes“ (source-only upload)
    - Use „dput package_version-revision_arch.changes“ (source+binary upload)

Test building and confirming of the binary package goodness as above is the moral obligation as a diligent Debian developer but there is no physical barrier for people to skip such operations at this moment for the source-only upload.

For the upstream tarball, the debmake command helps up to the step 4 in the above workflow. For the upstream working tree package/ checked out, e.g., by „git clone https://github.com/upstreamname/package.git“ without any upstream tarball, the debmake command invoked in it helps up to step 4, too. The debmake command does not overwrite any existing configuration files.

Here, please replace each part of the filename as:

- the package part with the Debian source package name
- the binarypackage part with the Debian binary package name
- the version part with the upstream version
- the revision part with the Debian revision
- the arch part with the package architecture (e.g., amd64)

The current Debian practice for uploading the normal Debian package is:

- Use the source-only upload if all generated binary packages exist in the Debian sid archive. This is usual case.
- Use the source+binary upload if any one of generated packages is missing in the Debian sid archive. (This involves manually handled NEW process by the archive management team.)

See also „Source-only uploads“.

| Tipp
Many patch management and VCS usage strategies for the Debian packaging are practiced. You don’t need to use all of them.

| Tipp
There is very extensive documentation in „Chapter 6. Best Packaging Practices“ in the „Debian Developer’s Reference“. Please read it.

## 6.2. debhelper package

Although a Debian package can be made by writing a debian/rules script without using the debhelper package, it is impractical to do so. There are too many modern „Debian Policy“ required features to be addressed, such as application of the proper file permissions, use of the proper architecture dependent library installation path, insertion of the installation hook scripts, generation of the debug symbol package, generation of package dependency information, generation of the package information files, application of the proper timestamp for reproducible build, etc.

Debhelper package provides a set of useful scripts in order to simplify Debian’s packaging workflow and reduce the burden of package maintainers. When properly used, they will help packagers handle and implement „Debian Policy“ required features automatically.

The modern Debian packaging workflow can be organized into a simple modular workflow by:

- using the dh command to invoke many utility scripts automatically from the debhelper package, and
- configuring their behavior with declarative configuration files in the debian/ directory.

You should almost always use debhelper as your package’s build dependency. This document also assumes that you are using a fairly contemporary version of debhelper to handle packaging works in the following contents.

| Anmerkung
For debhelper „compat >= 9“, the dh command exports compiler flags (CFLAGS, CXXFLAGS, FFLAGS, CPPFLAGS and LDFLAGS) with values as returned by dpkg-buildflags if they are not set previously. (The dh command calls set_buildflags defined in the Debian::Debhelper::Dh_Lib module.)

| Anmerkung
debhelper(1) changes its behavior with time. Please make sure to read debhelper-compat-upgrade-checklist(7) to understand the situation.

## 6.3. Paketname und -version

If the upstream source comes as hello-0.9.12.tar.xz, you can take hello as the upstream source package name and 0.9.12 as the upstream version.

There are some limitations for what characters may be used as a part of the Debian package. The most notable limitation is the prohibition of uppercase letters in the package name. Here is a summary as a set of regular expressions:

- Upstream package name (-p): `[-+.a-z0-9]{2,}`
- Binary package name (-b): `[-+.a-z0-9]{2,}`
- Upstream version (-u): `[0-9][-+.:~a-z0-9A-Z]*`
- Debian revision (-r): `[0-9][+.~a-z0-9A-Z]*`

See the exact definition in „Chapter 5 - Control files and their fields“ in the „Debian Policy Manual“.

You must adjust the package name and upstream version accordingly for the Debian packaging.

In order to manage the package name and version information effectively under popular tools such as the aptitude command, it is a good idea to keep the length of package name to be equal or less than 30 characters; and the total length of version and revision to be equal or less than 14 characters. [12]

In order to avoid name collisions, the user visible binary package name should not be chosen from any generic words.

If upstream does not use a normal versioning scheme such as 2.30.32 but uses some kind of date such as 11Apr29, a random codename string, or a VCS hash value as part of the version, make sure to remove them from the upstream version. Such information can be recorded in the debian/changelog file. If you need to invent a version string, use the YYYYMMDD format such as 20110429 as upstream version. This ensures that the dpkg command interprets later versions correctly as upgrades. If you need to ensure a smooth transition to a normal version scheme such as 0.1 in the future, use the 0~YYMMDD format such as 0~110429 as upstream version, instead.

Version strings can be compared using the dpkg command as follows.

    [~] $ dpkg --compare-versions ver1 op ver2

The version comparison rule can be summarized as:

- Strings are compared from the head to the tail.
- Letters are larger than digits.
- Numbers are compared as integers.
- Letters are compared in ASCII code order.

There are special rules for period (.), plus (+), and tilde (~) characters, as follows.

    0.0 < 0.5 < 0.10 < 0.99 < 1 < 1.0~rc1 < 1.0 < 1.0+b1 < 1.0+nmu1 < 1.1 < 2.0

One tricky case occurs when the upstream releases hello-0.9.12-ReleaseCandidate-99.tar.xz as the pre-release of hello-0.9.12.tar.xz. You can ensure the Debian package upgrade to work properly by renaming the upstream source to hello-0.9.12~rc99.tar.xz.

## 6.4. Natives Debian-Paket

The non-native Debian package in the Debian source format „3.0 (quilt)“ is the most normal Debian source package format. The debian/source/format file should have „3.0 (quilt)“ in it as described in dpkg-source(1). The above workflow and the following packaging examples always use this format.

A native Debian package is the rare Debian binary package format. It may be used only when the package is useful and valuable only for Debian. Thus, its use is generally discouraged.

| Achtung
A native Debian package is often accidentally built when its upstream tarball is not accessible from the dpkg-buildpackage command with its correct name package_version.orig.tar.xz . This is a typical newbie mistake caused by making a symlink name with „-“ instead of the correct one with „_“.

A native Debian package has no separation between the upstream code and the Debian changes and consists only of the following:

- package_version.tar.xz (copy or symlink of package-version.tar.xz with debian/* files.)
- package_version.dsc

If you need to create a native Debian package, create it in the Debian source format „3.0 (native)“ using dpkg-source(1).

| Tipp
There is no need to create the tarball in advance if the native Debian package format is used. The debian/source/format file should have „3.0 (native)“ in it as described in dpkg-source(1) and The debian/source/format file should have the version without the Debian revision (1.0 instead of 1.0-1). Then, the tarball containing is generated when „dpkg-source -b“ is invoked in the source tree.

## 6.5. debian/rules file

The debian/rules file is the executable script which re-targets the upstream build system to install files in the $(DESTDIR) and creates the archive file of the generated files as the deb file. The deb file is used for the binary distribution and installed to the system using the dpkg command.

The Debian policy compliant debian/rules file supporting all the required targets can be written as simple as [13]:

Simple debian/rules:

    #!/usr/bin/make -f
    #export DH_VERBOSE = 1

    %:
    	dh $@

The dh command functions as the sequencer to call all required „dh target“ commands at the right moment. [14]

- dh clean: bereinigt Dateien in dem Quellbaum.
- dh build : build the source tree
- dh build-arch : build the source tree for architecture dependent packages
- dh build-indep : build the source tree for architecture independent packages
- dh install : install the binary files to $(DESTDIR)
- dh install-arch : install the binary files to $(DESTDIR) for architecture dependent packages
- dh install-indep : install the binary files to $(DESTDIR) for architecture independent packages
- dh binary : generate the deb file
- dh binary-arch : generate the deb file for architecture dependent packages
- dh binary-indep : generate the deb file for architecture independent packages

Here, $(DESTDIR) path depends on the build type.

- „DESTDIR=debian/binarypackage/“ for single binary package [15]
- „DESTDIR=debian/tmp/“ for multi binary package

See „Abschnitt 9.2, „Customized debian/rules““ and „Abschnitt 9.3, „Variables for debian/rules““ for customization.

| Tipp
Setting „export DH_VERBOSE = 1“ outputs every command that modifies files on the build system. Also it enables verbose build logs for some build systems.

## 6.6. debian/control file

The debian/control file consists of blocks of metadata separated by blank lines. Each block of metadata defines the following, in this order:

- Metadaten für das Debian-Quellpaket
- Metadaten für das Debian-Binärpaket

See „Chapter 5 - Control files and their fields“ of the "Debian Policy Manual" for the definition of each metadata field.

| Anmerkung
The debmake command sets the debian/control file with „Build-Depends: debhelper-compat (= 14)“ to set the debhelper compatibility level.

| Tipp
If an existing package has a debhelper compatibility level lower than 14, it’s probably time to update its packaging.

## 6.7. debian/changelog file

The debian/changelog file records the Debian package history.

- Edit this file using the debchange command (alias dch).
- The first line defines the upstream package version and the Debian revision.

- Document changes in a specific, formal, and concise style.

  - If Debian maintainer modification fixes reported bugs, add „Closes: #<bug_number>“ to close those bugs.

- Even if you’re uploading your package yourself, you must document all non-trivial user-visible changes, such as:

  - Security-related bug fixes.
  - User interface changes.

- If you’re asking a sponsor to upload it, document changes more comprehensively, including all packaging-related ones, to help with package review.

  - The sponsor shouldn’t have to guess your reasoning behind package changes.
  - Remember that the sponsor’s time is valuable.

After finishing your packaging and verifying its quality, execute the "dch -r" command and save the finalized debian/changelog file with the suite normally set to unstable. [16] If you’re packaging for backports, security updates, LTS, etc., use the appropriate distribution names instead.

The debmake command creates the initial template file with the upstream package version and the Debian revision. The distribution is set to UNRELEASED to prevent accidental uploads to the Debian archive.

| Tipp
The date string used in the debian/changelog file can be manually generated by the „LC_ALL=C date -R“ command.

| Tipp
Use a debian/changelog entry with a version string like 1.0.1-1~rc1 when experimenting. Later, consolidate such changelog entries into a single entry for the official package.

The debian/changelog file is installed in the /usr/share/doc/binarypackage directory as changelog.Debian.gz by the dh_installchangelogs command.

Der Changelog der Originalautoren wird als changelog.gz in das Verzeichnis /usr/share/doc/Binärpaket installiert.

The upstream changelog is automatically found by the dh_installchangelogs using the case insensitive match of its file name to changelog, changes, changelog.txt, changes.txt, history, history.txt, or changelog.md and searched in the ./ doc/ or docs/ directories.

## 6.8. debian/copyright file

Debian takes copyright and license matters very seriously. The "Debian Policy Manual" requires a summary of these in the debian/copyright file of the package.

- „12.5. Copyright information“
- „2.3. Copyright considerations“
- „License information“

The debmake command creates the initial debian/copyright template file using the licensecheck(1) command.

## 6.9. debian/patches/* files

As demonstrated in „Abschnitt 5.9, „Step 3 (alternatives): Modification to the upstream source““, the debian/patches/ directory holds

- patch-file-name.patch files providing -p1 patches and
- the series file which defines how these patches are applied.

See how these files are used in:

- „Abschnitt 13.6, „dpkg-source -b““ to build the Debian source package
- „Abschnitt 13.7, „dpkg-source -x““ to extract source files from the Debian source package

| Anmerkung
Header texts of these patches should conform to „DEP-3“.

| Anmerkung
If you want to use VCS tools such as git, gbp and dgit to create and manage these patches after learning basics here, please refer to later in „Kapitel 11, Packaging with git“.

## 6.10. debian/source/include-binaries file

The „dpkg-source --commit“ command functions like dquilt but has one advantage over the dquilt command. The dquilt command can’t handle modified binary files since they are not representable in a diff. Also, adding binary files under the debian/ directory is normally rejected by dpkg-source. By listing these binary files in debian/source/include-binaries, the maintainer can include these binary files to the Debian source package generated by dpkg-source.

## 6.11. debian/watch file

| Anmerkung
This file is for use by the Debian non-native package.

The uscan(1) command downloads the latest upstream version using the debian/watch file. E.g.:

Basic debian/watch file:

    version=4
    https://ftp.gnu.org/gnu/hello/ @PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@

The uscan command may verify the authenticity of the upstream tarball with optional configuration (see „Abschnitt 6.12, „debian/upstream/signing-key.asc file““).

See uscan(1), „Abschnitt 9.4, „New upstream release““, „Abschnitt 8.1, „Fix with Files-Excluded““, and „Abschnitt 11.7, „Manage patch queue with gbp-pq““ for more.

## 6.12. debian/upstream/signing-key.asc file

Some packages are signed by a openPGP key and their authenticity can be verified using their public openPGP key.

For example, „GNU hello“ can be downloaded via HTTP from https://ftp.gnu.org/gnu/hello/ . There are sets of files:

- hello-version.tar.xz (upstream source)
- hello-version.tar.xz.sig (detached signature)

Let’s pick the latest version set.

Download the upstream tarball and its signature.

    [base_dir] $ wget https://ftp.gnu.org/gnu/hello/hello-2.9.tar.xz
     ...
    [base_dir] $ wget https://ftp.gnu.org/gnu/hello/hello-2.9.tar.xz.sig
     ...
    [base_dir] $ gpg --verify hello-2.9.tar.xz.sig
    gpg: Signature made Thu 10 Oct 2013 08:49:23 AM JST using DSA key ID 80EE4A00
    gpg: Can't check signature: public key not found

If you know the public openPGP key of the upstream maintainer from the mailing list, use it as the debian/upstream/signing-key.asc file. Otherwise, use the hkp keyserver and check it via your web of trust.

Download public openPGP key for the upstream.

    [base_dir] $ gpg --keyserver hkp://keys.gnupg.net --recv-key 80EE4A00
    gpg: requesting key 80EE4A00 from hkp server keys.gnupg.net
    gpg: key 80EE4A00: public key "Reuben Thomas <rrt@sc3d.org>" imported
    gpg: no ultimately trusted keys found
    gpg: Total number processed: 1
    gpg:               imported: 1
    [base_dir] $ gpg --verify hello-2.9.tar.xz.sig
    gpg: Signature made Thu 10 Oct 2013 08:49:23 AM JST using DSA key ID 80EE4A00
    gpg: Good signature from "Reuben Thomas <rrt@sc3d.org>"
      ...
    Primary key fingerprint: 9297 8852 A62F A5E2 85B2  A174 6808 9F73 80EE 4A00

| Tipp
If your network environment blocks access to the HKP port 11371, use „hkp://keyserver.ubuntu.com:80“ instead.

After confirming the key ID 80EE4A00 is a trustworthy one, download its public key into the debian/upstream/signing-key.asc file.

Set public openPGP key to debian/upstream/signing-key.asc.

    [base_dir] $ gpg --armor --export 80EE4A00 >debian/upstream/signing-key.asc

With the above debian/upstream/signing-key.asc file and the following debian/watch file, the uscan command can verify the authenticity of the upstream tarball after its download. E.g.:

Improved debian/watch file with openPGP support:

    version=4
    opts="pgpsigurlmangle=s/$/.sig/" \
    https://ftp.gnu.org/gnu/hello/ @PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@

## 6.13. debian/salsa-ci.yml file

Install Salsa CI configuration file. See „Abschnitt 11.3, „Salsa CI service““.

## 6.14. Other debian/* files

Optional configuration files may be added under the debian/ directory. Most of them are to control dh_* commands offered by the debhelper package but there are some for dpkg-source, lintian and gbp commands.

| Tipp
Even an upstream source without its build system can be packaged just by using these files. See „Abschnitt 14.2, „Kein Makefile (Shell, CLI)““ as an example.

The alphabetical list of notable optional debian/binarypackage.* configuration files listed below provides very powerful means to set the installation path of files. Please note:

- The „-x[01234]“ superscript notation that appears in the following list indicates the minimum value for the debmake -x option that generates the associated template file. See „Abschnitt 16.4, „debmake -x““ or debmake(1) for details.
- For a single binary package, the „binarypackage.“ part of the filename in the list may be removed.
- For a multi binary package, a configuration file missing the „binarypackage“ part of the filename is applied to the first binary package listed in the debian/control.
- When there are many binary packages, their configurations can be specified independently by prefixing their name to their configuration filenames such as „package-1.install“, „package-2.install“, etc.
- Some template configuration files may not be created by the debmake command. In such cases, you need to create them with an editor.
- Some configuration template files generated by the debmake command with an extra .ex suffix need to be activated by removing that suffix.
- The debmake -B command adds template files with an extra .ex suffix for all existing template files without .ex and they need to be activated by removing that suffix.
- Nicht verwendete Vorlagendateien, die durch den Befehl debmake erstellt wurden, sollten entfernt werden.

- Kopieren Sie die Konfigurationsvorlagendateien wie benötigt nach den Dateinamen, die ihren Programmpaketnamen entsprechen.

  binarypackage.bug-control -x2
    installed as usr/share/bug/binarypackage/control in binarypackage. See „Abschnitt 9.11, „Bug reports““.
  binarypackage.bug-presubj -x2
    installed as usr/share/bug/binarypackage/presubj in binarypackage. See „Abschnitt 9.11, „Bug reports““.
  binarypackage.bug-script -x2
    installed as usr/share/bug/binarypackage or usr/share/bug/binarypackage/script in binarypackage. See „Abschnitt 9.11, „Bug reports““.
  Binärpaket.bash-completion

    List bash completion scripts to be installed.

    The bash-completion package is required for both build and user environments.

    Siehe dh_bash-completion(1).

  clean -x1

    List files that should be removed but are not cleaned by the dh_auto_clean command.

    Siehe dh_auto_clean(1) und dh_clean(1).

  compat -x4

    Set the debhelper compatibility level. (deprecated)

    Use „Build-Depends: debhelper-compat (= 14)“ in debian/control to specify the compatibility level and remove debian/compat.

    See „COMPATIBILITY LEVELS“ in debhelper(7).

  binarypackage.conffiles -x3

    This optional file is installed into the DEBIAN directory within the binary package while supplementing it with all the conffiles auto-detected by debhelper.

    This file is primarily useful for using "special" entries such as the remove-on-upgrade feature from dpkg(1).

    If the program you’re packaging requires every user to modify the configuration files in the /etc directory, there are two popular ways to arrange for them not to be conffiles, keeping the dpkg command happy and quiet.

    - Create a symlink under the /etc directory pointing to a file under the /var directory generated by the maintainer scripts.
    - Create a file generated by the maintainer scripts under the /etc directory.

    Siehe dh_installdeb(1).

  binarypackage.config
    This is the debconf config script used for asking any questions necessary to configure the package. See „Abschnitt 10.22, „debconf““.
  Binärpaket.cron.hourly -x3

    Installed into the etc/cron/hourly/binarypackage file in binarypackage.

    Siehe dh_installcron(1) und cron(8).

  Binärpaket.cron.daily -x3

    Installed into the etc/cron/daily/binarypackage file in binarypackage.

    Siehe dh_installcron(1) und cron(8).

  Binärpaket.cron.weekly -x3

    Installed into the etc/cron/weekly/binarypackage file in binarypackage.

    Siehe dh_installcron(1) und cron(8).

  Binärpaket.cron.monthly -x3

    Installed into the *etc/cron/monthly/*binarypackage file in binarypackage.

    Siehe dh_installcron(1) und cron(8).

  Binärpaket.cron.d -x3

    Installed into the etc/cron.d/binarypackage file in binarypackage.

    Siehe dh_installcron(1), cron(8) und crontab(5).

  Binärpaket.default -x3

    If this exists, it is installed into etc/default/binarypackage in binarypackage.

    Siehe dh_installinit(1).

  binarypackage.dirs -x1

    List directories to be created in binarypackage.

    Siehe dh_installdirs(1).

    Usually, this is not needed since all dh_install* commands create required directories automatically. Use this only when you run into trouble.

  binarypackage.doc-base -x1

    Installed as the doc-base control file in binarypackage.

    See dh_installdocs(1) and „Debian doc-base Manual (doc-base.html)“ provided by the doc-base package.

  binarypackage.docs -x1

    List documentation files to be installed in binarypackage.

    Siehe dh_installdocs(1).

  binarypackage.emacsen-compat

    Installed into usr/lib/emacsen-common/packages/compat/binarypackage in binarypackage.

    Siehe dh_installemacsen(1).

  Binärpaket.emacsen-install -x3

    Installed into usr/lib/emacsen-common/packages/install/binarypackage in binarypackage.

    Siehe dh_installemacsen(1).

  Binärpaket.emacsen-remove -x3

    Installed into usr/lib/emacsen-common/packages/remove/binarypackage in binarypackage.

    Siehe dh_installemacsen(1).

  Binärpaket.emacsen-startup -x3

    Installed into usr/lib/emacsen-common/packages/startup/binarypackage in binarypackage.

    Siehe dh_installemacsen(1).

  binarypackage.examples -x1

    List example files or directories to be installed into usr/share/doc/binarypackage/examples/ in binarypackage.

    Siehe dh_installexamples(1).

  gbp.conf -x1

    Falls diese existiert, funktioniert sie als Konfigurationsdatei für den Befehl gbp.

    Siehe gbp.conf(5), gbp(1) und git-buildpackage(1).

  binarypackage.info -x1

    Führt Info-Dateien auf, die in Binärpaket installiert werden.

    Siehe dh_installinfo(1).

  binarypackage.init -x4

    Installed into etc/init.d/binarypackage in binarypackage. (deprecated)

    Siehe dh_installinit(1).

  binarypackage.install -x1

    Liste der Dateien, die installiert werden sollten, aber nicht durch den Befehl dh_auto_install installiert wurden.

    Siehe dh_install(1) und dh_auto_install(1).

  binarypackage.links -x1

    List pairs of source and destination files to be symlinked. Each pair should be put on its own line, with the source and destination separated by whitespace.

    Siehe dh_link(1).

  binarypackage.lintian-overrides -x2

    Installed into usr/share/lintian/overrides/binarypackage in the package build directory. This file is used to suppress erroneous lintian diagnostics.

    Siehe dh_lintian(1), lintian(1) und „Lintian User’s Manual“.

  binarypackage.maintscript -x2

    If this optional file exists, debhelper uses this as the template to generate DEBIAN/binarypackage.{pre,post}{inst,rm} files within the binary package while adding „-- "$@"“ to the dpkg-maintscript-helper(1) command.

    See dh_installdeb(1) and „Chapter 6 - Package maintainer scripts and installation procedure“ in the „Debian Policy Manual“.

  manpage.* -x2

    These are manpage template files generated by the debmake command. Please rename these to appropriate file names and update their contents.

    Debian Policy requires that each program, utility, and function should have an associated manual page included in the same package. Manual pages are written in nroff(1). If you are new to making a manpage, use manpage.asciidoc -x3 or manpage.1 -x3 as the starting point.

  binarypackage.manpages -x1

    List man pages to be installed.

    Siehe dh_installman(1).

  Binärpaket.menu (veraltet, nicht mehr installiert)

    tech-ctte #741573 decided „Debian should use .desktop files as appropriate“.

    Debian menu file installed into usr/share/menu/binarypackage in binarypackage.

    See menufile(5) for its format. See dh_installmenu(1).

  NEWS

    Installed into usr/share/doc/binarypackage/NEWS.Debian.

    Siehe dh_installchangelogs(1).

  patches/*

    Collection of -p1 patch files which are applied to the upstream source before building the source.

    No patch files are generated by the debmake command.

    Siehe dpkg-source(1), „Abschnitt 4.4, „quilt setup““ und „Abschnitt 5.9, „Step 3 (alternatives): Modification to the upstream source““.

  patches/series -x1
    The application sequence of the patches/* patch files.
  binarypackage.preinst -x3, binarypackage.postinst -x3, binarypackage.prerm -x3, binarypackage.postrm -x3

    If these optional files exist, the corresponding files are installed into the DEBIAN directory within the binary package after enriched by debhelper. Otherwise, these files in the DEBIAN directory within the binary package is generated by debhelper.

    Whenever possible, simpler binarypackage.maintscript should be used instead.

    See dh_installdeb(1) and „Chapter 6 - Package maintainer scripts and installation procedure“ in the „Debian Policy Manual“.

    See also debconf-devel(7) and „3.9.1 Prompting in maintainer scripts“ in the „Debian Policy Manual“.

  README.Debian -x1

    Installed into the first binary package listed in the debian/control file as usr/share/doc/binarypackage/README.Debian.

    This file provides the information specific to the Debian package.

    Siehe dh_installdocs(1).

  README.source -x1

    Installed into the first binary package listed in the debian/control file as usr/share/doc/binarypackage/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 this file is recommended.

    See „Debian policy manual section 4.14“.

  binarypackage.service -x3

    If this exists, it is installed into lib/systemd/system/binarypackage.service in binarypackage.

    Siehe dh_systemd_enable(1), dh_systemd_start(1) und dh_installinit(1).

  source/format -x1

    The Debian package format.

    - Use „3.0 (quilt)“ to make this non-native package (popular)
    - Use „3.0 (native)“ to make this native package

    See „SOURCE PACKAGE FORMATS“ in dpkg-source(1).

  source/lintian-overrides -x2

    This file is not installed, but is scanned by the lintian command to provide overrides for the source package.

    Siehe dh_lintian(1) und lintian(1).

  source/local-options and source/local-patch-header -x4

    | Anmerkung
    These files are not compatible with the dgit workflow. See „Abschnitt 11.14, „Note on dgit““.

    There is no reason to use these with the current version of dpkg-source(1).

  source/options -x2

    The dpkg-source command uses this content as its options. This is typically used with „Abschnitt 11.13, „Patch applied Git repository““ and options may be:

    - auto-commit
    - single-debian-patch

    This is included in the generated source package.

    See „FILE FORMATS“ in dpkg-source(1).

  source/patch-header -x2

    Free form text that is put on top of the automatic patch generated.

    This is included in the generated source package and is meant to be committed to the "`Abschnitt 11.13, „Patch applied Git repository“`.".

    See „FILE FORMATS“ in dpkg-source(1).

  binarypackage.symbols -x1

    The symbols files, if present, are passed to the dpkg-gensymbols command to be processed and installed.

    Siehe dh_makeshlibs(1) und „Abschnitt 10.16, „Bibliothekssymbole““..

  binarypackage.templates
    This is the debconf templates file used for asking any questions necessary to configure the package. See „Abschnitt 10.22, „debconf““.
  tests/control -x1
    This is the RFC822-style test meta data file defined in DEP-8. See autopkgtest(1) and „Abschnitt 10.4, „Continuous integration““.
  TODO

    Installed into the first binary package listed in the debian/control file as usr/share/doc/binarypackage/TODO.Debian.

    Siehe dh_installdocs(1).

  Binärpaket.tmpfile -x3

    If this exists, it is installed into usr/lib/tmpfiles.d/binarypackage.conf in binarypackage.

    Siehe dh_systemd_enable(1), dh_systemd_start(1) und dh_installinit(1).

  binarypackage.upstart -x4

    If this exists, it is installed into etc/init/package.conf in the package build directory. (deprecated)

    Siehe dh_installinit(1).

  upstream/metadata -x1
    Per-package machine-readable metadata about upstream (DEP-12). See „Upstream MEtadata GAthered with YAml (UMEGAYA)“.

[11] This is the default up to debhelper v13. At debhelper v14, it warns the default change. After debhelper v15, it will change the default to DESTDIR=debian/tmp/ .

[12] For more than 90% of packages, the package name is equal or less than 24 characters; the upstream version is equal or less than 10 characters and the Debian revision is equal or less than 3 characters.

[13] The debmake command generates a bit more complicated debian/rules file. But this is the core part.

[14] This simplicity is available since version 7 of the debhelper package. This guide assumes the use of debhelper version 14 or newer.

[15] This is the default up to debhelper v13. At debhelper v14, it warns the default change. After debhelper v15, it will change the default to DESTDIR=debian/tmp/ .

[16] If you’re using the vim editor, make sure to save this with the ":wq" command.

Kapitel 5. Simple packaging |  | Kapitel 7. Quality of packaging