Kapitel 5. Grundlagen

Inhaltsverzeichnis

5.1. Arbeitsablauf des Paketierens
5.1.1. Das Paket debhelper
5.2. Paketname und -version
5.3. Natives Debian-Paket
5.4. debian/rules
5.4.1. dh
5.4.2. Einfache debian/rules
5.4.3. Angepasste debian/rules
5.4.4. Variablen für debian/rules
5.4.5. Reproduzierbares Bauen
5.5. debian/control
5.5.1. Aufteilung eines Debian-Binärpakets
5.5.1.1. debmake -b
5.5.1.2. Pakettrennungsszenarien und -beispiele
5.5.1.3. Der Bibliothekspaketname
5.5.2. Substvar
5.5.3. biNMU-sicher
5.6. debian/changelog
5.7. debian/copyright
5.8. debian/patches/*
5.8.1. dpkg-source -x
5.8.2. dquilt und dpkg-source
5.9. debian/upstream/signing-key.asc
5.10. debian/watch und DFSG
5.11. Weitere debian/*-Dateien
5.12. Anpassung der Debian-Paketierung
5.13. Aufzeichnen im VCS (standard)
5.14. Aufzeichnen im VCS (Alternative)
5.15. Pakete ohne irrelevante Inhalte bauen
5.15.1. Korrektur durch debian/rules clean
5.15.2. Korrektur mittels VCS
5.15.3. Korrektur durch extend-diff-ignore
5.15.4. Korrektur durch tar-ignore
5.16. Bausysteme der Originalautoren
5.16.1. Autotools
5.16.2. CMake
5.16.3. Python Distutils
5.17. Fehlersuchinformationen
5.17.1. Neue -dbgsym-Pakete (Stretch 9.0 und danach)
5.18. Bibliothekspaket
5.18.1. Bibliothekssymbole
5.18.2. Bibliotheksübergänge
5.19. Debconf
5.20. Multiarch
5.20.1. The multiarch library path
5.20.2. The multiarch header file path
5.20.3. The multiarch *.pc file path
5.21. Compiler hardening
5.22. Continuous integration
5.23. Bootstrapping
5.24. Bug reports

A broad overview is presented here for the basic rules of Debian packaging focusing on the non-native Debian package in the “3.0 (quilt)” format.

[Anmerkung] Anmerkung

Some details are intentionally skipped for clarity. Please read the manpages of the dpkg-source(1), dpkg-buildpackage(1), dpkg(1), dpkg-deb(1), deb(5), etc.

The Debian source package is a set of input files used to build the Debian binary package and is not a single file.

The Debian binary package is a special archive file which holds a set of installable binary data with its associated information.

A single Debian source package may generate multiple Debian binary packages defined in the debian/control file.

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

[Anmerkung] Anmerkung

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

Der Arbeitsablauf beim Paketieren, um ein Debian-Binärpaket zu erstellen, beinhaltete die Erstellung mehrere Dateien mit bestimmten Namen (siehe Abschnitt 5.2, „Paketname und -version“), wie dies in dem »Debian Policy Manual« definiert ist.

Stark vereinfacht kann der Arbeitsablauf beim Debian-Paketieren in folgende 5 Schritte zusammengefasst werden:

  1. Der Tarball der Originalautoren wird als Datei Paket-Version.tar.gz heruntergeladen.
  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.gz.

    • 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 5.4, „debian/rules“)
      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 5.5, „debian/control“)
      debian/changelog
      The Debian package history file defining the upstream package version and the Debian revision in its first line (see Abschnitt 5.6, „debian/changelog“)
      debian/copyright
      The copyright and license summary (see Abschnitt 5.7, „debian/copyright“)
    • Optional specification files under the debian/* (see Abschnitt 5.11, „Weitere debian/*-Dateien“):
    • The debmake command invoked in the package-version/ directory provides the initial set of these template configuration files.

      • Required specification files are generated even with the -x0 option.
      • The debmake command does not overwrite any existing configuration 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 pdebuild) 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 “3.0 (quilt)” format using dpkg-source(1)

      • package_version.orig.tar.gz (copy or symlink of package-version.tar.gz)
      • package_version-revision.debian.tar.xz (tarball of package-version/debian/*)
      • package_version-revision.dsc
    • Build the source using “debian/rules build” into $(DESTDIR)

      • DESTDIR=debian/binarypackage/ (single binary package)
      • DESTDIR=debian/tmp/ (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
  6. Check the quality of the Debian package with the lintian command. (recommended)

  7. Sign the package_version-revision.dsc and package_version-revision_arch.changes files with the debsign command using your private GPG key.
  8. Upload the set of the Debian source and binary package files with the dput command to the Debian archive.

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
[Tipp] Tipp

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

[Tipp] Tipp

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

Falls die Quellen der Originalautoren als hello-0.9.12.tar.gz vorliegen, könen Sie hello als Namen des Quellpakets der Originalautoren und 0.9.12 als Version der Originalautoren nehmen.

debmake is meant to provide template files for the package maintainer to work on. Comment lines started by # contain the tutorial text. You must remove or edit such comment lines before uploading to the Debian archive.

The license extraction and assignment process involves a lot of heuristics; it may fail in some cases. It is highly recommended to use other tools such as licensecheck from the devscripts package in conjunction with debmake.

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”.

debmake assumes relatively simple packaging cases. So all programs related to the interpreter are assumed to be "Architecture: all". This is not always true.

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. [10]

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.gz as the pre-release of hello-0.9.12.tar.gz. You can ensure the Debian package upgrade to work properly by renaming the upstream source to hello-0.9.12~rc99.tar.gz.

The non-native Debian package in the “3.0 (quilt)” format 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] 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.gz . 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.gz (copy or symlink of package-version.tar.gz with debian/* files.)
  • package_version.dsc

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

[Tipp] Tipp

Some people promote packaging even programs that have been written only for Debian in the non-native package format. The required tarball without debian/* files needs to be manually generated in advance before the standard workflow in Abschnitt 5.1, „Arbeitsablauf des Paketierens“. [11] They claim that the use of non-native package format eases communication with the downstream distributions.

[Tipp] Tipp

There is no need to create the tarball in advance if the native package format is used. The native Debian package can be created by setting the debian/source/format file to “3.0 (native)”, setting the debian/changelog file to have the version without the Debian revision (1.0 instead of 1.0-1), and invoking the “dpkg-source -b .” command within the source tree. The tarball containing the source is generated by this.

Das Skript debian/rules ist das ausführbare Skript, um das Debian-Paket zu bauen.

Thanks to this abstraction of the dh command [12], 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 $@

Essentially, this dh command functions as the sequencer to call all required dh_* commands at the right moment.

[Anmerkung] Anmerkung

The debmake command sets the debian/control file with “Build-Depends: debhelper (>=9)” and the debian/compat file with “9”.

[Tipp] 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.

Flexible customization of the debian/rules script is realized by adding appropriate override_dh_* targets and their rules.

Whenever some special operation is required for a certain dh_foo command invoked by the dh command, any automatic execution of it can be overridden by adding the makefile target override_dh_foo in the debian/rules file.

The build process may be customized via the upstream provided interface such as arguments to the standard source build system commands, such as:

  • configure,
  • Makefile,
  • setup.py oder
  • Build.PL.

If this is the case, you should add the override_dh_auto_build target and executing the “dh_auto_build -- arguments” command. This ensures passing arguments to the such build system after the default parameters that dh_auto_build usually passes.

[Tipp] Tipp

Please try not to execute the above build system commands directly if they are supported by the dh_auto_build command.

The debmake command creates the initial template file taking advantage of the above simple debian/rules file example while adding some extra customizations for package hardening, etc. You need to know how underlying build systems work under the hood (see Abschnitt 5.16, „Bausysteme der Originalautoren“) to address their irregularities using package customization.

Some variable definitions useful for customizing debian/rules can be found in files under /usr/share/dpkg/. Notably:

pkg-info.mk
DEB_SOURCE, DEB_VERSION, DEB_VERSION_EPOCH_UPSTREAM, DEB_VERSION_UPSTREAM_REVISION, DEB_VERSION_UPSTREAM, and DEB_DISTRIBUTION variables. These are useful for backport support etc..
vendor.mk
DEB_VENDOR and DEB_PARENT_VENDOR variables; and dpkg_vendor_derives_from macro. These are useful for vendor support (Debian, Ubuntu, …).
architecture.mk
Set DEB_HOST_* and DEB_BUILD_* variables. An alternative method of retrieving those variables is to invoke dpkg-architecture directly and query the value of a single variable. With explicit invocation of dpkg-architecture to retrieve necessary variables, there is no need to include architecture.mk in debian/rules, which would import all architecture-related variables.
buildflags.mk
Setzt die Bauschalter CFLAGS, CPPFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS, FCFLAGS und LDFLAGS.

If you wish to use some of these useful variables in debian/rules, copy relevant code to debian/rules or write a simpler alternative in it. Please keep debian/rules simple.

Beispielsweise können Sie eine Zusatzoption zu CONFIGURE_FLAGS für die Zielarchitektur linux-any durch Hinzufügen von folgendem zur debian/rules hinzufügen:

DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
 ...
ifeq ($(DEB_HOST_ARCH_OS),linux)
CONFIGURE_FLAGS += --enable-wayland
endif
[Tipp] Tipp

It was useful to include buildflags.mk in debian/rules to set the build flags such as CPPFLAGS, CFLAGS, LDFLAGS, etc. properly while honoring DEB_CFLAGS_MAINT_APPEND, DEB_BUILD_MAINT_OPTIONS, etc. for the debhelper “compat <= 8”. Now you should use the debhelper “compat >= 9”, should not include buildflags.mk without specific reasons, and should let the dh command set these build flags.

Siehe Abschnitt 5.20, „Multiarch“, dpkg-architecture(1) und dpkg-buildflags(1).

Die Datei debian/control besteht aus Metadatenblöcken, die durch Leerzeilen getrennt sind. Jeder Metadatenblock definiert folgendes in dieser Reihenfolge:

  • 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 meta data.

For well behaving build systems, the split of a Debian binary package into small ones can be realized as follows.

  • Create binary package entries for all binary packages in the debian/control file.
  • List all file paths (relative to debian/tmp) in the corresponding debian/binarypackage.install files.

Bitte prüfen Sie die Beispiele in dieser Anleitung:

The debmake command with the -b option provides an intuitive and flexible method to create the initial template debian/control file defining the split of the Debian binary packages with following stanzas:

  • Package:
  • Architecture:
  • Multi-Arch:
  • Depends:
  • Pre-Depends:

The debmake command also sets an appropriate set of substvars used in each pertinent dependency stanza.

Let’s quote the pertinent part from the debmake manpage here.

-b "binarypackage[:type],…", --binaryspec "binarypackage[:type],…"

set the binary package specs by a comma separated list of binarypackage:type pairs, e.g., in the full form “foo:bin,foo-doc:doc,libfoo1:lib,libfoo-dev:dev” or in the short form, “-doc,libfoo1,libfoo-dev”.

Here, binarypackage is the binary package name, and the optional type is chosen from the following type values:

  • bin: C/C++ compiled ELF binary code package (any, foreign) (default, alias: "", i.e., null-string)
  • data: Data (fonts, graphics, …) package (all, foreign) (alias: da)
  • dev: Library development package (any, same) (alias: de)
  • doc: Documentation package (all, foreign) (alias: do)
  • lib: Library package (any, same) (alias: l)
  • perl: Perl script package (all, foreign) (alias: pl)
  • python: Python script package (all, foreign) (alias: py)
  • python3: Python3 script package (all, foreign) (alias: py3)
  • ruby: Ruby script package (all, foreign) (alias: rb)
  • script: Shell script package (all, foreign) (alias: sh)

The pair values in the parentheses, such as (any, foreign), are the Architecture and Multi-Arch stanza values set in the debian/control file.

In many cases, the debmake command makes good guesses for type from binarypackage. If type is not obvious, type is set to bin. For example, libfoo sets type to lib, and font-bar sets type to data, …

If the source tree contents do not match settings for type, the debmake command warns you.

Let’s consider that the upstream source tarball of the libfoo library is updated from libfoo-7.0.tar.gz to libfoo-8.0.tar.gz with a new SONAME major version which affects other packages.

The binary library package must be renamed from libfoo7 to libfoo8 to keep the unstable suite system working for all dependent packages after the upload of the package based on the libfoo-8.0.tar.gz.

[Warnung] Warnung

If the binary library package isn’t renamed, many dependent packages in the unstable suite become broken just after the library upload even if a binNMU upload is requested. The binNMU may not happen immediately after the upload due to several reasons.

The -dev package must follow one of the following naming rules:

[Tipp] Tipp

If the data encoding scheme changes (e.g., latin1 to utf-8), the same care as the API change needs to be taken.

Siehe Abschnitt 5.18, „Bibliothekspaket“.

The debian/control file also defines the package dependency in which the variable substitutions mechanism (substvar) may be used to free package maintainers from chores of tracking most of the simple package dependency cases. See deb-substvars(5).

The debmake command supports the following substvars:

  • ${misc:Depends} for all binary packages
  • ${misc:Pre-Depends} for all multiarch packages
  • ${shlibs:Depends} for all binary executable and library packages
  • ${python:Depends} for all Python packages
  • ${python3:Depends} for all Python3 packages
  • ${perl:Depends} for all Perl packages
  • ${ruby:Depends} for all Ruby packages

For the shared library, required libraries found simply by "objdump -p /path/to/program | grep NEEDED" are covered by the shlib substvar.

For Python and other interpreters, required modules found simply looking for lines with “import”, “use”, “require”, etc., are covered by the corresponding substvars.

For other programs which do not deploy their own substvars, the misc substvar covers their dependency.

For POSIX shell programs, there is no easy way to identify the dependency and no substvar covers their dependency.

For libraries and modules required via the dynamic loading mechanism including the GObject introspection mechanism, there is no easy way to identify the dependency and no substvar covers their dependency.

A binNMU is a binary-only non-maintainer upload performed for library transitions etc. In a binNMU upload, only the “Architecture: any” packages are rebuilt with a suffixed version number (e.g. version 2.3.4-3 will become 2.3.4-3+b1). The “Architecture: all” packages are not built.

The dependency defined in the debian/control file among binary packages from the same source package should be safe for the binNMU. This needs attention if there are both “Architecture: any” and “Architecture: all” packages involved in it.

  • Architecture: any” package: depends on “Architecture: anyfoo package

    • Depends: foo (= ${binary:Version})
  • Architecture: any” package: depends on “Architecture: allbar package

    • Depends: bar (= ${source:Version}
  • Architecture: all” package: depends on “Architecture: anybaz package

    • Depends: baz (>= ${source:Version}), baz (<< ${source:Upstream-Version}.0~)

The debian/changelog file records the Debian package history and defines the upstream package version and the Debian revision in its first line. The changes need to be documented in the specific, formal, and concise style.

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

    • sicherheitsrelevante Änderungen
    • Änderungen in der Benutzerschnittstelle
  • If you are asking your sponsor to upload it, you should document changes more comprehensively, including all packaging related ones, to help reviewing your package.

    • The sponsor shouldn’t second guess your thought behind your package.
    • Die Zeit des Sponsorers ist wertvoller als Ihre.

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 upload to the Debian archive.

Der Befehl debchange (auch als dch bekannt) wird typischerweise zur Bearbeitung dieser Datei verwandt.

[Tipp] Tipp

Sie können die Datei debian/changelog händisch mit einem beliebigen Texteditor bearbeiten, solange Sie den von debchange verwandten Formatierungskonventionen folgen.

[Tipp] Tipp

Die in der Datei debian/changelog verwandte Datumszeichenkette kann mit dem Befehl »LC_ALL=C date -R« manuell erstellt werden.

Dieser wird durch den Befehl dh_installchangelogs als changelog.Debian.gz in das Verzeichnis /usr/share/doc/Binärpaket installiert.

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.

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

Debian takes the copyright and license matters very seriously. The “Debian Policy Manual” enforces having a summary of them in the debian/copyright file in the package.

Sie sollten es als maschinenlesbare Datei debian/copyright (DEP-5) formatieren.

[Achtung] Achtung

Die Datei debian/copyright sollte sortiert sein, um die generischen Dateimuster am Anfang der Liste zu behalten. Siehe Abschnitt 6.4, „debmake -k“.

Der Befehl debmake erstellt die anfängliche, DEP-5-kompatible Vorlagendatei, indem er den gesamten Quellbaum überprüft. Er verwendet einen internen Lizenzprüfer, um jeden Lizenztext auszuwerten. [15]

Unless specifically requested to be pedantic with the -P option, the debmake command skips reporting for auto-generated files with permissive licenses to be practical.

[Anmerkung] Anmerkung

Falls Sie Probleme mit diesem Lizenzprüfer feststellen, reichen Sie bitten gegen das Paket debmake einen Fehlerbericht mit dem problematischen Teil des Textes, der das Copyright und die Lizenz enthält, ein.

[Anmerkung] Anmerkung

The debmake command focuses on bunching up same copyright and license claims in detail to create template for debian/copyright. In order to do this within reasonable time, it only picks the first section which looks like copyright and license claims. So its license assignment may not be optimal. Please also use other tools such as licensecheck.

[Tipp] Tipp

You are highly encouraged to check the license status with the licensecheck(1) command and, as needed, with your manual code review.

The -p1 patches in the debian/patches/ directory are applied in the sequence defined in the debian/patches/series file to the upstream source tree before the build process.

[Anmerkung] Anmerkung

Das native Debian-Paket (siehe Abschnitt 5.3, „Natives Debian-Paket“) verwendet dieseDateien nicht.

There are several methods to prepare a series of -p1 patches.

  • Der Befehl diff

    • Siehe Abschnitt 4.8.1, „Patch durch diff -u“
    • Primitive but versatile method

      • Patches may come from other distros, mailing list postings, or cherry-picked patches from the upstream git repository with the “git format-patches” command
    • Missing the .pc/ directory
    • Unmodified upstream source tree
    • Manually update the debian/patches/series file
  • Der Befehl dquilt

  • Der Befehl »dpkg-source --commit«

  • The automatic patch generation by the dpkg-buildpackage

  • Der Befehl gbp-pq

    • basic git work flow with the git-buildpackage package
    • Missing the .pc/ directory
    • Modified upstream source tree in the throw-away branch (patch-queue/master)
    • Unmodified upstream source tree in the Debian branch (master)
  • Der Befehl gbp-dpm

    • more elaborate git work flow with the git-dpm package
    • Missing the .pc/ directory
    • Modified upstream source tree in the patched branch (patched/whatever)
    • Unmodified upstream source tree in the Debian branch (master/whatever)

Wherever these patches come from, it is a good idea to tag them with a DEP-3 compatible header.

[Tipp] Tipp

The dgit package offers an alternative git integration tool with the Debian package archive.

The quilt command (or its wrapped dquilt command) was needed to manage the -p1 patches in the debian/patches/ directory before the --commit feature was added to the dpkg-source command in 1.16.1.

The patches should apply cleanly when using the dpkg-source command. Thus you can’t just copy the patches to the new packaging of the new upstream release if there are patch offsets, etc.

The dquilt command (see Abschnitt 3.4, „Quilt“) is more forgiving. You can normalize the patches by the dquilt command.

 $ while dquilt push; do dquilt refresh ; done
 $ dquilt pop -a

There is one advantage of using the dpkg-source command over the dquilt command. While the dquilt command cannot handle modified binary files automatically, the dpkg-source command detects modified binary files and lists them in the debian/source/include-binaries file to include them in the Debian tarball.

Some packages are signed by a GPG 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.gz (upstream source)
  • hello-version.tar.gz.sig (detached signature)

Let’s pick the latest version set.

$ wget https://ftp.gnu.org/gnu/hello/hello-2.9.tar.gz
 ...
$ wget https://ftp.gnu.org/gnu/hello/hello-2.9.tar.gz.sig
 ...
$ gpg --verify hello-2.9.tar.gz.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 GPG 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.

$ 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
$ gpg --verify hello-2.9.tar.gz.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] 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.

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

Setzen Sie dann die entsprechende Datei debian/watch wie folgt:

version=4
pgpsigurlmangle=s/$/.sig/  https://ftp.gnu.org/gnu/hello/ hello-(\d[\d.]*)\.tar\.(?:gz|bz2|xz)

Jetzt wird der Befehl uscan die Echtheit des Pakets mittels GPG-Signaturen prüfen.

Debian nimmt die Freiheit von Software ernst und folgt der DFSG.

The non-DFSG components in the upstream source tarball can be easily removed when the uscan command is used to update the Debian package.

  • List the files to be removed in the Files-Excluded stanza of the debian/copyright file.
  • List the URL to download the upstream tarball in the debian/watch file.
  • Führen Sie den Befehl uscan aus, um einen neuen Tarball der Originalautoren herunterzuladen.

    • Verwenden Sie alternativ den Befehl »gbp import-orig --uscan --pristine-tar«.
  • Der resultierende Tarball hat die Versionsnummer mit einer zusätzlichen Endung +dfsg.

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] Tipp

Check debhelper(7) for the latest available set of the dh_* commands.

These debian/binarypackage.* files provide very powerful means to set the installation path of files. Even an upstream source without its build system can be packaged just by using these files. See Abschnitt 8.2, „Kein Makefile (Shell, CLI)“ as an example.

The "-x[1234]" superscript notation that appears in the following list indicates the minimum value for the debmake -x option that will generate the associated template file. See Abschnitt 6.6, „debmake -x“ or debmake(1) for details.

Here is the alphabetical list of notable optional configuration files.

Binärpaket.bug-control -x3
installed as usr/share/bug/binarypackage/control in binarypackage. See Abschnitt 5.24, „Bug reports“.
Binärpaket.bug-presubj -x3
installed as usr/share/bug/binarypackage/presubj in binarypackage. See Abschnitt 5.24, „Bug reports“.
Binärpaket.bug-script -x3
installed as usr/share/bug/binarypackage or usr/share/bug/binarypackage/script in binarypackage. See Abschnitt 5.24, „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 -x2

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 -x1

Set the debhelper compatibility level (currently, “9”).

See “COMPATIBILITY LEVELS” in debhelper(8).

Binärpaket .conffile

No need for this file under “compat >= 3” since all files in the etc/ directory are conffiles.

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).

Binärpaket .config
This is the debconf config script used for asking any questions necessary to configure the package. See Abschnitt 5.19, „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).

Binärpaket.dirs -x3

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.

Binärpaket.doc-base -x2

Installed as the doc-base control file in binarypackage.

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

Binärpaket.docs -x2

List documentation files to be installed in binarypackage.

Siehe dh_installdocs(1).

Binärpaket.emacsen-compat -x3

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).

Binärpaket.examples -x2

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

Siehe dh_installexamples(1).

gbp.conf

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

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

Binärpaket.info -x2

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

Siehe dh_installinfo(1).

Binärpaket.init -x3

Installiert in etc/init.d/Binärpaket in Binärpaket.

Siehe dh_installinit(1).

Binärpaket.install -x2

List files which should be installed but are not installed by the dh_auto_install command.

Siehe dh_install(1) und dh_auto_install(1).

license-examples/* -x4

These are copyright file examples generated by the debmake command. Use these as the reference for making the copyright file.

Please make sure to erase these files.

Binärpaket.links -x2

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).

Binärpaket.lintian-overrides -x3

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.

manpage.* -x3

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 or manpage.1 as the starting point.

Binärpaket.manpages -x2

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.

Siehe dpkg-source(1), Abschnitt 3.4, „Quilt“ und Abschnitt 4.8, „Schritt 3 (alternativ): Änderungen der Quellen der Originalautoren“.

No patch files are generated by the debmake command.

patches/series -x1
The application sequence of the patches/* patch files.
Binärpaket.preinst -x2, Binärpaket.postinst -x2, Binärpaket.prerm -x2, Binärpaket.postrm -x2

These maintainer scripts are installed into the DEBIAN directory.

Inside the scripts, the token #DEBHELPER# is replaced with shell script snippets generated by other debhelper commands.

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.

Siehe dh_installdocs(1).

This file provides the information specific to the Debian package.

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 (recommended)
  • Use “3.0 (native)” to make this native package

Siehe »QUELLPAKET-FORMATE« in dpkg-source(1).

source/lintian-overrides or source.lintian-overrides -x3

These files are not installed, but will be scanned by the lintian command to provide overrides for the source package.

Siehe dh_lintian(1) und lintian(1).

source/local-options -x1

The dpkg-source command uses this content as its options. Notable options are:

  • unapply-patches
  • abort-on-upstream-changes
  • auto-commit
  • single-debian-patch

This is not included in the generated source package and is meant to be committed to the VCS of the maintainer.

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

source/local-patch-header

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

This is not included in the generated source package and is meant to be committed to the VCS of the maintainer.

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

Binärpaket.symbols -x2

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

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

Binärpaket .templates
This is the debconf templates file used for asking any questions necessary to configure the package. See Abschnitt 5.19, „Debconf“.
tests/control
This is the RFC822-style test meta data file defined in DEP-8. See autopkgtest(1) and Abschnitt 5.22, „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).

Binärpaket.upstart -x3

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

Siehe dh_installinit(1) und Abschnitt 8.1, „Cherry-pick templates“.

watch -x1

The control file for the uscan command to download the latest upstream version.

This control file may be configured to verify the authenticity of the tarball using its GPG signature (see Abschnitt 5.9, „debian/upstream/signing-key.asc“).

Siehe Abschnitt 5.10, „debian/watch und DFSG“ und uscan(1).

Here are a few reminders for the above list.

  • 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.
  • Unusual configuration template files generated by the debmake command with an extra .ex suffix 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.

Let’s recap the customization of the Debian packaging.

All customization data for the Debian package resides in the debian/ directory. A simple example is given in Abschnitt 4.6, „Schritt 3: Anpassung der Vorlagendateien“. Normally, this customization involves a combination of the following:

When these are not sufficient to make a good Debian package, modifications to the upstream source recorded as the -p1 patches in the debian/patches/ directory is deployed. These patches are applied in the sequence defined in the debian/patches/series file before building the package (see Abschnitt 5.8, „debian/patches/*“). Simple examples are given in Abschnitt 4.8, „Schritt 3 (alternativ): Änderungen der Quellen der Originalautoren“.

You should address the root cause of the Debian packaging problem by the least invasive way. The generated package shall be more robust for future upgrades in this way.

[Anmerkung] Anmerkung

Schicken Sie den Patch, der das eigentliche Problem adressiert, an die Originalautoren, falls er für die Originalautoren nützlich ist.

Typischerweise wird Git als VCS benutzt, um die Debian-Paketieraktivitäten mit den nachfolgenden Verzweigungen aufzuzeichnen.

  • master branch

    • Record the source tree used for the Debian packaging.
    • The upstream portion of the source tree is recorded unmodified.
    • The upstream modifications for the Debian packaging are recorded in the debian/patches/ directory as the -p1 patches.
  • upstream branch

    • Record the upstream source tree untarred from the released upstream tarball.
[Tipp] Tipp

It’s a good idea to add to the .gitignore file the listing .pc.

[Tipp] Tipp

Add unapply-patches and abort-on-upstream-changes lines to the debian/source/local-options file to keep the upstream portion unmodified.

[Tipp] Tipp

You may also track the upstream VCS data with a branch different from the upstream branch to ease cherry-picking of patches.

You may not wish to keep up with creating the -p1 patch files for all upstream changes needed. You can record the Debian packaging activity with the following branches.

  • master branch

    • Record the source tree used for the Debian packaging.
    • The upstream portion of the source tree is recorded with modifications for the Debian packaging.
  • upstream branch

    • Record the upstream source tree untarred from the released upstream tarball.

Adding a few extra files in the debian/ directory enables you to do this.

 $ tar -xvzf <package-version>.tar.gz
 $ ln -sf <package_version>.orig.tar.gz
 $ cd <package-version>/
 ... hack...hack...
 $ echo "single-debian-patch" >> debian/source/local-options
 $ cat >debian/source/local-patch-header <<END
 This patch contains all the Debian-specific changes mixed
 together. To review them separately, please inspect the VCS
 history at https://git.debian.org/?=collab-maint/foo.git.

Let the dpkg-source command invoked by the Debian package build process (dpkg-buildpackage, debuild, …) generate the -p1 patch file debian/patches/debian-changes automatically.

[Tipp] Tipp

This approach can be adopted for any VCS tools. Since this approach merges all changes into a merged patch, it is desirable to keep the VCS data publicly accessible.

[Tipp] Tipp

The debian/source/local-options and debian/source/local-patch-header files are meant to be recorded in the VCS. These aren’t included in the Debian source package.

Es gibt ein paar Fälle, die zur Aufnahme von ungewünschten Inhalten in das erstellte Debian-Quellpaket führen.

  • The upstream source tree may be placed under the version control system. When the package is rebuilt from this source tree, the generated Debian source package contains extraneous contents from the version control system files.
  • The upstream source tree may contain some auto-generated files. When the package is rebuilt from this source tree, the generated Debian source package contains extraneous contents from the auto-generated files.

Normally, the -i and -I options set in Abschnitt 3.5, „Devscripts“ for the dpkg-source command should avoid these. Here, the -i option is aimed at the non-native package while the -I is aimed at the native package. See dpkg-source(1) and the “dpkg-source --help” output.

Es gibt mehrere Methoden, die Aufnahme ungewünschter Inhalte zu vermeiden

Upstream build systems are designed to go through several steps to install generated binary files to the system from the source distribution.

[Tipp] Tipp

Before attempting to make a Debian package, you should become familiar with the upstream build system of the upstream source code and try to build it.

Das Debian-Paket wird mit den Fehlersuchinformationen gebaut, aber in das Binärpaket nach entfernen der Fehlersuchinformationen paketiert, wie von Kapitel 10 - Dateien des »Debian Policy Manual« verlangt.

Siehe

Die Paketierung von Bibliothekssoftware verlangt von Ihnen deutlich mehr Arbeit als normal. Es folgen ein paar Erinnerungen zur Paketierung von Bibliothekssoftware:

Before packaging shared library software, see:

For the historic background study, see:

The symbols support in dpkg introduced in Debian lenny (5.0, May 2009) helps us to manage the backward ABI compatibility of the library package with the same package name. The DEBIAN/symbols file in the binary package provides the minimal version associated with each symbol.

An oversimplified method for the library packaging is as follows.

  • Extract the old DEBIAN/symbols file of the immediate previous binary package with the “dpkg-deb -e” command.

    • Alternatively, the mc command may be used to extract the DEBIAN/symbols file.
  • Copy it to the debian/binarypackage.symbols file.

    • If this is the first package, use an empty content file instead.
  • Build the binary package.

    • If the dpkg-gensymbols command warns about some new symbols:

      • Extract the updated DEBIAN/symbols file with the “dpkg-deb -e” command.
      • Trim the Debian revision such as -1 in it.
      • Copy it to the debian/binarypackage.symbols file.
      • Re-build the binary package.
    • If the dpkg-gensymbols command does not warn about new symbols:

      • You are done with the library packaging.

For the details, you should read the following primary references.

Sie sollten auch Folgendes prüfen:

[Tipp] Tipp

For C++ libraries and other cases where the tracking of symbols is problematic, follow 8.6.4 The shlibs system of the “Debian Policy Manual”, instead. Please make sure to erase the empty debian/binarypackage.symbols file generated by the debmake command. For this case, the DEBIAN/shlibs file is used.

The debconf package enables us to configure packages during their installation in 2 main ways:

  • non-interactively from the debian-installer pre-seeding.
  • interactively from the menu interface (dialog, gnome, kde, …)

    • the package installation: invoked by the dpkg command
    • the installed package: invoked by the dpkg-reconfigure command

All user interactions for the package installation must be handled by this debconf system using the following files.

  • debian/binarypackage.config

    • This is the debconf config script used for asking any questions necessary to configure the package.
  • debian/binarypackage.template

    • This is the debconf templates file used for asking any questions necessary to configure the package.
  • package configuration scripts

    • debian/binarypackage.preinst
    • debian/binarypackage.prerm
    • debian/binarypackage.postinst
    • debian/binarypackage.postrm

See dh_installdebconf(1), debconf(7), debconf-devel(7) and 3.9.1 Prompting in maintainer scripts in the “Debian Policy Manual”.

Multiarch support for cross-architecture installation of binary packages (particularly i386 and amd64, but also other combinations) in the dpkg and apt packages introduced in Debian wheezy (7.0, May 2013), demands that we pay extra attention to packaging.

You should read the following references in detail.

The multiarch is enabled by using the <triplet> value such as i386-linux-gnu and x86_64-linux-gnu in the install path of shared libraries as /usr/lib/<triplet>/, etc..

  • The <triplet> value required internally by debhelper scripts is implicitly set in themselves. The maintainer doesn’t need to worry.
  • The <triplet> value used in override_dh_* target scripts must be explicitly set in the debian/rules file by the maintainer. The <triplet> value is stored in the $(DEB_HOST_MULTIARCH) variable in the following debian/rules snippet example:

    DEB_HOST_MULTIARCH = $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
    ...
    override_dh_install:
            mkdir -p package1/lib/$(DEB_HOST_MULTIARCH)
            cp -dR tmp/lib/. package1/lib/$(DEB_HOST_MULTIARCH)

See:

Debian policy requires following Filesystem Hierarchy Standard. Its /usr/lib : Libraries for programming and packages states "/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts."

Debian policy makes an exception to the Filesystem Hierarchy Standard to use /usr/lib/<triplet>/ instead of /usr/lib<qual>/ (e.g., /lib32/ and /lib64/) to support a multiarch library.


For Autotools based packages under the debhelper package (compat>=9), this path setting is automatically taken care by the dh_auto_configure command.

For other packages with non-supported build systems, you need to manually adjust the install path as follows.

  • If “./configure” is used in the override_dh_auto_configure target in debian/rules, make sure to replace it with “dh_auto_configure --” while re-targeting the install path from /usr/lib/ to /usr/lib/$(DEB_HOST_MULTIARCH)/.
  • Replace all occurrences of /usr/lib/ with /usr/lib/*/ in debian/foo.install files.

All files installed simultaneously as the multiarch package to the same file path should have exactly the same file content. You must be careful with differences generated by the data byte order and by the compression algorithm.

[Anmerkung] Anmerkung

The --libexecdir option of the ./configure command specifies the default path to install executable programs run by other programs rather than by users. Its Autotools default is /usr/libexec/ but its Debian non-multi-arch default is /usr/lib/. If such executables are a part of a "Multi-arch: foreign" package, a path such as /usr/lib/ or /usr/lib/packagename may be more desirable than /usr/lib/<triplet>/, which dh_auto_configure uses. The GNU Coding Standards: 7.2.5 Variables for Installation Directories has a description for libexecdir as "The definition of libexecdir is the same for all packages, so you should install your data in a subdirectory thereof. Most packages install their data under $(libexecdir)/package-name/ …". (It is always a good idea to follow GNU unless it conflicts with the Debian policy.)

The shared library files in the default path /usr/lib/ and /usr/lib/<triplet>/ are loaded automatically.

For shared library files in another path, the GCC option -l must be set by the pkg-config command to make them load properly.

The compiler hardening support spreading for Debian jessie (8.0, TBA) demands that we pay extra attention to the packaging.

You should read the following references in detail.

The debmake command adds template comments to the debian/rules file as needed for DEB_BUILD_MAINT_OPTIONS, DEB_CFLAGS_MAINT_APPEND, and DEB_LDFLAGS_MAINT_APPEND (see Kapitel 4, Einfaches Beispiel and dpkg-buildflags(1)).

DEP-8 defines the debian/tests/control file as the RFC822-style test metadata file for continuous integration (CI) of the Debian package.

It is used after building the binary packages from the source package containing this debian/tests/control file. When the autopkgtest command is run, the generated binary packages are installed and tested in the virtual environment according to this file.

See documents in the /usr/share/doc/autopkgtest/ directory and 3. autopkgtest: Automatic testing for packages of the “Ubuntu Packaging Guide”.

There are several other CI tools on Debian for you to explore.

  • The debci package: CI platform on top of the autopkgtest package
  • The jenkins package: generic CI platform

Debian cares about supporting new ports or flavours. The new ports or flavours require bootstrapping operation for the cross-build of the initial minimal native-building system. In order to avoid build-dependency loops during bootstrapping, the build-dependency needs to be reduced using the profile builds feature.

[Tipp] Tipp

If a core package foo build depends on a package bar with deep build dependency chains but bar is only used in the test target in foo, you can safely mark the bar with <!nocheck> in the Build-depends of foo to avoid build loops.

The reportbug command used for the bug report of binarypackage can be customized by the files in usr/share/bug/binarypackage/.

The dh_bugfiles command installs these files from the template files in the debian/ directory.

  • debian/binarypackage.bug-controlusr/share/bug/binarypackage/control

    • This file contains some directions such as redirecting the bug report to another package.
  • debian/binarypackage.bug-presubjusr/share/bug/binarypackage/presubj

    • This file is displayed to the user by the reportbug command.
  • debian/binarypackage.bug-scriptusr/share/bug/binarypackage or usr/share/bug/binarypackage/script

    • The reportbug command runs this script to generate a template file for the bug report.

Siehe dh_bugfiles(1) und reportbug’s Features for Developers

[Tipp] Tipp

If you always remind the bug reporter of something or ask them about their situation, use these files to automate it.



[10] 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.

[11] Use of the “debmake -t …” command can help this workflow. See Abschnitt 6.2, „Schnappschuss der Originalautoren (-d, -t)“.

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

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

[14] If you are using the vim editor, make sure to save this with the “:wq” command.

[15] The licensecheck command from the devscripts package was referenced to make this internal checker. Now the licensecheck command is provided in an independent licensecheck package with a lot of improvements.

[16] This document was written before the introduction of the symbols file.

[17] The strong preference is to use the SONAME versioned -dev package names over the single -dev package name in Chapter 6. Development (-DEV) packages, which does not seem to be shared by the former ftp-master (Steve Langasek). This document was written before the introduction of the multiarch system and the symbols file.

[18] This path is compliant with the FHS. Filesystem Hierarchy Standard: /usr/lib : Libraries for programming and packages states "Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory."