| Chapter 6. Basics for packaging | ||
|---|---|---|
 |
 |
|
| Chapter 6. Basics for packaging | ||
|---|---|---|
| |
|
|
Table of Contents
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.
![[Note]](images/note.png) | Note |
|---|---|
|
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.
| Note |
|---|---|
|
There are many wrapper scripts. Use them to streamline your workflow but make sure to understand the basics of their internals. |
The Debian packaging workflow to create a Debian binary package involves generating several specifically named files (see “Section 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.
The upstream tarball is copied (or symlinked) to the particular filename packagename_version.orig.tar.gz.
The Debian package specification files are added to the upstream source under the package-version/debian/ directory.
Required specification files under the debian/ directory:
The debmake command invoked in the package-version/ directory may be used to provide the initial template of these configuration files.
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.
Create the Debian source package in the Debian source format “3.0 (quilt)” using dpkg-source(1)
Build the source using “debian/rules build” into $(DESTDIR)
Create the Debian binary package using dpkg-deb(1), dpkg-genbuildinfo(1), and dpkg-genchanges(1).
Check the quality of the Debian package with the lintian command. (recommended)
Follow the rejection guidelines from ftp-master.
Sign the Debian package file with the debsign command using your private GPG key.
Upload the set of the Debian package files with the dput command to the Debian archive.
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.
Here, please replace each part of the filename as:
See also “Source-only uploads”.
![[Tip]](images/tip.png) | Tip |
|---|---|
|
Many patch management and VCS usage strategies for the Debian packaging are practiced. You don’t need to use all of them. |
| Tip |
|---|---|
|
There is very extensive documentation in “Chapter 6. Best Packaging Practices” in the “Debian Developer’s Reference”. Please read it. |
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:
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.
| Note |
|---|---|
|
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.) |
| Note |
|---|---|
|
debhelper(1) changes its behavior with time. Please make sure to read debhelper-compat-upgrade-checklist(7) to understand the situation. |
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.
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:
[-+.a-z0-9]{2,}
[-+.a-z0-9]{2,}
[0-9][-+.:~a-z0-9A-Z]*
[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:
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 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.
![[Caution]](images/caution.png) | Caution |
|---|---|
|
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:
If you need to create a native Debian package, create it in the Debian source format “3.0 (native)” using dpkg-source(1).
| Tip |
|---|---|
|
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. |
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]
Here, $(DESTDIR) path depends on the build type.
See “Section 8.2, “Customized debian/rules”” and “Section 8.3, “Variables for debian/rules”” for customization.
| Tip |
|---|---|
|
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. |
Die Datei debian/control besteht aus Metadatenblöcken, die durch Leerzeilen getrennt sind. Jeder Metadatenblock definiert folgendes in dieser Reihenfolge:
See “Chapter 5 - Control files and their fields” of the “Debian Policy Manual” for the definition of each meta data.
| Note |
|---|---|
|
The debmake command sets the debian/control file with “Build-Depends: debhelper-compat (= 13)” to set the debhelper compatibility level. |
| Tip |
|---|---|
|
If an existing package has lower than debhelper compatibility level 13, probably it’s time to update its packaging. |
The debian/changelog file records the Debian package history.
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:
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.
After finishing your packaging and verifying its quality, please execute the “dch -r” command and save the finalized debian/changelog file with the suite normally set to unstable. [16] If you are packaging for backports, security updates, LTS, etc., please 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 upload to the Debian archive.
| Tip |
|---|---|
|
The date string used in the debian/changelog file can be manually generated by the “LC_ALL=C date -R” command. |
| Tip |
|---|---|
|
Use a debian/changelog entry with a version string such as 1.0.1-1~rc1 when you experiment. Then, unclutter 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.
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.
The debmake command creates the initial debian/copyright template file.
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.
| Caution |
|---|---|
|
Die Datei debian/copyright sollte sortiert sein, um die generischen Dateimuster am Anfang der Liste zu behalten. Siehe “Section 15.6, “debmake -k””. |
| Note |
|---|---|
|
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. |
As demonstrated in “Section 5.9, “Step 3 (alternatives): Modification to the upstream source””, the debian/patches/ directory holds
See how these files are used in:
| Note |
|---|---|
|
Header texts of these patches should conform to “DEP-3”. |
| Note |
|---|---|
|
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 “Chapter 10, Packaging with git”. |
The “dpkg-source --commit” command functions like dquilt but has one advantage over the dquilt command. While the dquilt command can’t handle modified binary files, the “dpkg-source --commit” command detects modified binary files and lists them in the debian/source/include-binaries file to include them in the Debian tarball as a part of the Debian source 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 “Section 6.12, “debian/upstream/signing-key.asc file””).
See uscan(1), “Section 8.4, “New upstream release””, “Section 7.1, “Fix with Files-Excluded””, and “Section 10.10, “Manage patch queue with gbp-pq”” for more.
Some packages are signed by a GPG key and their authenticity can be verified using their public GPG key.
For example, “GNU hello” can be downloaded via HTTP from https://ftp.gnu.org/gnu/hello/ . There are sets of files:
Let’s pick the latest version set.
Download the upstream tarball and its signature.
$ 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.
Download public GPG key for the upstream.
$ 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
| Tip |
|---|---|
|
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 GPG key to debian/upstream/signing-key.asc.
$ 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 GPG support:
version=4 opts="pgpsigurlmangle=s/$/.sig/" \ https://ftp.gnu.org/gnu/hello/ @PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
Install Salsa CI configuration file. See “Section 10.3, “Salsa CI service””.
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.
| Tip |
|---|---|
|
Even an upstream source without its build system can be packaged just by using these files. See “Section 13.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:
Kopieren Sie die Konfigurationsvorlagendateien wie benötigt nach den Dateinamen, die ihren Programmpaketnamen entsprechen.
List bash completion scripts to be installed.
The bash-completion package is required for both build and user environments.
Siehe dh_bash-completion(1).
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).
Set the debhelper compatibility level. (deprecated)
Use “Build-Depends: debhelper-compat (= 13)” in debian/control to specify the compatibility level and remove debian/compat.
See “COMPATIBILITY LEVELS” in debhelper(7).
This optional file is installed into the DEBIAN directory within the binary package while supplimenting 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.
Siehe dh_installdeb(1).
Installed into the etc/cron/hourly/binarypackage file in binarypackage.
Siehe dh_installcron(1) und cron(8).
Installed into the etc/cron/daily/binarypackage file in binarypackage.
Siehe dh_installcron(1) und cron(8).
Installed into the etc/cron/weekly/binarypackage file in binarypackage.
Siehe dh_installcron(1) und cron(8).
Installed into the *etc/cron/monthly/*binarypackage file in binarypackage.
Siehe dh_installcron(1) und cron(8).
Installed into the etc/cron.d/binarypackage file in binarypackage.
Siehe dh_installcron(1), cron(8) und crontab(5).
If this exists, it is installed into etc/default/binarypackage in binarypackage.
Siehe dh_installinit(1).
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.
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.
List documentation files to be installed in binarypackage.
Siehe dh_installdocs(1).
Installed into usr/lib/emacsen-common/packages/compat/binarypackage in binarypackage.
Siehe dh_installemacsen(1).
Installed into usr/lib/emacsen-common/packages/install/binarypackage in binarypackage.
Siehe dh_installemacsen(1).
Installed into usr/lib/emacsen-common/packages/remove/binarypackage in binarypackage.
Siehe dh_installemacsen(1).
Installed into usr/lib/emacsen-common/packages/startup/binarypackage in binarypackage.
Siehe dh_installemacsen(1).
List example files or directories to be installed into usr/share/doc/binarypackage/examples/ in binarypackage.
Siehe dh_installexamples(1).
Falls diese existiert, funktioniert sie als Konfigurationsdatei für den Befehl gbp.
Siehe gbp.conf(5), gbp(1) und git-buildpackage(1).
Führt Info-Dateien auf, die in Binärpaket installiert werden.
Siehe dh_installinfo(1).
Installed into etc/init.d/binarypackage in binarypackage. (deprecated)
Siehe dh_installinit(1).
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).
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).
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”.
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”.
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.
List man pages to be installed.
Siehe dh_installman(1).
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).
Installed into usr/share/doc/binarypackage/NEWS.Debian.
Siehe dh_installchangelogs(1).
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), “Section 4.4, “quilt setup”” und “Section 5.9, “Step 3 (alternatives): Modification to the upstream source””.
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”.
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).
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.
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).
The Debian package format.
See “SOURCE PACKAGE FORMATS” in dpkg-source(1).
These file is not installed, but are scanned by the lintian command to provide overrides for the source package.
Siehe dh_lintian(1) und lintian(1).
The dpkg-source command uses this content as its options. Notable options are:
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).
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).
The symbols files, if present, are passed to the dpkg-gensymbols command to be processed and installed.
Siehe dh_makeshlibs(1) und “Section 9.16, “Bibliothekssymbole””..
Installed into the first binary package listed in the debian/control file as usr/share/doc/binarypackage/TODO.Debian.
Siehe dh_installdocs(1).
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).
If this exists, it is installed into etc/init/package.conf in the package build directory. (deprecated)
Siehe dh_installinit(1).
[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 13 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 are using the vim editor, make sure to save this with the “:wq” command.
| |
|
|
| Chapter 5. Simple packaging |
|
Chapter 7. Sanitization of the source |