Table of Contents
It’s time to learn the basic rules of the Debian packaging.
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 their 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 binary 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 the Debian binary package involves generating several specifically named files (see Section 5.2, “Package name and version”) as defined in the “Debian Policy Manual”.
The oversimplified method for the Debian packaging workflow can be summarized in 5 steps 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/*:
The debmake command invoked in the package-version/ directory provides the initial set of these template configuration files.
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.
Create the Debian source package in the “3.0 (quilt)” format using dpkg-source(1)
Build the source using “debian/rules build” into $(DESTDIR)
Create the Debian binary package using dpkg-deb(1), and dpkg-genchanges(1).
Check the quality of the Debian package with the lintian command. (recommended)
Follow the rejection guideline from ftp-master.
Here, please replace each part of the filename as:
![]() |
Tip |
---|---|
There is very extensive documentation in Chapter 6. Best Packaging Practices of the “Debian Developer’s Reference”. Please read it. |
If the upstream source comes as hello-0.9.12.tar.gz, you can take hello as the upstream source package name and 0.9.12 as the upstream version.
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.
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 the summary in the regular expression.
See the exact definition in Chapter 5 - Control files and their fields of 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. [11]
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 dpkg interprets later versions correctly as upgrades. If you need to ensure smooth transition to the normal version scheme such as 0.1 in 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 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 upgrade to work properly by renaming the upstream source to hello-0.9.12~rc99.tar.gz having the proper version order.
The non-native Debian package in the “3.0 (quilt)” format is the most normal Debian binary package format. The above workflow and the following packaging examples always use this format.
The 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 deprecated.
![]() |
Caution |
---|---|
The 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 . A typical newbie mistake is to make a symlink name with “-” instead of the correct one with “_”. |
The native Debian package has no separation between the upstream code and the Debian changes and consists only with the following:
If you need to create the native Debian package, create it in the “3.0 (native)” format using dpkg-source(1).
![]() |
Tip |
---|---|
Some people promote to package even programs which 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 Section 5.1, “Packaging workflow”. [12] They claim that the use of non-native package format eases communication with the downstream distributions. |
The debian/rules script is the executable script to build the Debian package.
The debian/rules script re-targets the upstream build system (see Section 5.13, “Upstream build systems”) to install files in the $(DESTDIR) and creates the archive file of the generated files as the deb file.
$(DESTDIR) path depends on the build type.
The dh command from the debhelper package with the help from its associated packages functions as the wrapper to the typical upstream build systems and offers us with the uniform access to them by supporting all the Debian policy stipulated targets of the debian/rules file.
![]() |
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.) |
Thanks to this abstraction of the dh command [13], the Debian policy compliant debian/rules file supporting all the required targets can be written as simple as [14]:
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.
![]() |
Note |
---|---|
The debmake command sets the debian/control file with “Build-Depends: debhelper (>=9)” and the debian/compat file with “9”. |
![]() |
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. |
Flexible customization of the debian/rules 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 debmake command creates the initial template file taking advantage of the above simple debian/rules while adding some extra customizations for the package hardening, etc.
You need to know how underlying build systems work under the hood (see Section 5.13, “Upstream build systems”) to address their irregularities using the package customization.
See Chapter 4, Simple Example for the actual simple debian/rules generated by the debmake command which comes with the commented out parts addressing the hardening via compile options (see Section 5.18, “Compiler hardening”) and the multiarch customization (see Section 5.16, “Multiarch”).
Some variable definitions useful for customizing debian/rules can be found in files under /usr/share/dpkg/. Notably:
If you wish to use some of these useful variables in debian/rules, copy relevant codes to debian/rules or write a simpler alternative in it. Please keep debian/rules simple.
For example, you can add an extra option to CONFIGURE_FLAGS for linux-any target architectures by adding the followings to debian/rules:
DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) ... ifeq ($(DEB_HOST_ARCH_OS),linux) CONFIGURE_FLAGS += --enable-wayland endif
![]() |
Tip |
---|---|
It was useful to include buildflags.mk in the 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. |
See Section 5.16, “Multiarch”, dpkg-architecture(1) and dpkg-buildflags(1).
Here are some recommendations to attain the reproducible build result.
If the timestamp is needed, please consider to patch the upstream source to obtain the timestamp from the last entry in debian/changelog.
Shell code snippet example to obtain a formatted timestamp string:
date +'%Y-%m-%d' -d"`dpkg-parsechangelog -SDate`"
The debian/control file consists of blocks of meta data separated by the blank line. Each block of meta data defines the following in this order:
See Chapter 5 - Control files and their fields of the “Debian Policy Manual” for the definition of each meta data.
The debmake command with the -b option (see Section 5.6, “debmake -b”) creates the initial template debian/control file with followings:
For well behaving build systems, the split of the Debian binary package into small ones can be realized as follows.
Please check examples in this guide:
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 following substvars.
For the shared library, required libraries found simply by "objdump -p /path/to/program | grep NEEDED" are covered by the shlib substvar.
For the Python and other interpreters, required modules found simply looking for lines with “import”, “use”, “require”, etc., are covered by the corresponding substvar.
For other programs which do not deploy their own substvar, 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.
For the safe binNMU, the dependency among binary packages from a same source package needs attention if there are both “Architecture: any” and “Architecture: all” packages involved in it.
“Architecture: any” package depends on “Architecture: any” foo package
“Architecture: any” package depends on “Architecture: all” bar package
“Architecture: all” package depends on “Architecture: any” baz package
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 the 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.
![]() |
Warning |
---|---|
If the binary library package isn’t renamed, many dependent packages in the unstable suite become broken just after the library upload even if the binNMU 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:
Use the unversioned -dev package name: libfoo-dev
Only one version of the library source package is allowed in the archive.
Use the versioned -dev package names: libfoo7-dev and libfoo8-dev
Two versions of the library source packages are allowed simultaneously in the archive.
The -b option of the debmake command provides intuitive and flexible methods to customize packaging parameters in the debian/control file. It sets the following stanza values.
Let’s quote the pertinent part from the debmake manpage here.
Here are some typical multiarch package split scenarios for the following upstream source examples:
binarypackage | type | Architecture: | Multi-Arch: | Package content |
---|---|---|---|---|
lib foo1 |
lib * |
any |
same |
the shared library, co-installable |
lib foo1 -dbg |
dbg * |
any |
same |
the shared library debug symbols, co-installable |
lib foo -dev |
dev * |
any |
same |
the shared library header files etc., co-installable |
lib foo -tools |
bin * |
any |
foreign |
the run-time support programs, not co-installable |
lib foo -doc |
doc * |
all |
foreign |
the shared library documentation files |
bar |
bin * |
any |
foreign |
the compiled program files, not co-installable |
bar -doc |
doc * |
all |
foreign |
the documentation files for the program |
baz |
script |
all |
foreign |
the interpreted program files |
![]() |
Tip |
---|---|
The binary package name starting with a “-” (hyphen) is treated as the abbreviated name. The real binary package name is generated by attaching it to the source package name. |
For the cases marked with * in the above table, the type values are guessed right from the package names.
The default type is the bin type which means the compiled ELF binary executables. This is why the example in Chapter 4, Simple Example does not specify -b option.
For programs written in other compiled languages, you may need to add its run-time library package dependency to the resulting binary package by adjusting the Depends: stanza of the debian/control file.
The development package for the shared library should depend on it and should contain a version numberless symlink to it. E.g.: /usr/lib/x86_64-linux-gnu/libfoo.so → libfoo.so.1
![]() |
Note |
---|---|
The dbg type package can be made either one-on-one for each bin and lib type package or one-on-all for all bin and lib type packages. |
The debian/changelog file records the Debian package history and defines the upstream package version and the Debian revision in its first line.
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.
The debchange command (alias dch) is used to edit this.
![]() |
Tip |
---|---|
The date string used in the debian/changelog file can be manually generated by “LC_ALL=C date -R”. |
This is installed in the /usr/share/doc/binarypackage directory as changelog.Debian.gz by the dh_installchangelogs.
The upstream changelog is installed in the /usr/share/doc/binarypackage directory as changelog.gz.
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” and save the finalized debian/changelog file with the distribution normally set to unstable. [15] If you are packaging for the 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 to have summary of them in the debian/copyright file in the package.
You should format it as the machine-readable debian/copyright file (DEP-5).
![]() |
Caution |
---|---|
The debian/copyright file should be sorted to keep the generic file patterns at the top of the list. See Section 6.5, “debmake -k”. |
The debmake command creates the initial DEP-5 compatible template file by scanning the entire source tree. It uses an internal license checker to classify each license text. [16]
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.
![]() |
Note |
---|---|
If you find issues with this license checker, please file a bug report to the debmake package with the problematic part of text containing the copyright and license. |
![]() |
Note |
---|---|
The debmake command focuses on bunching up same copyright and license claims in details to create template for debian/copyright. In dorder 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 optiomal. Please also use other tools such as licensecheck which deploy simpler string match rules running on the whole source tree. |
Debian takes software freedom seriously and follows the 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.
Run the uscan command to download the new upstream tarball.
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 lintian and gbp commands. Here is the alphabetical list of notable optional configuration files.
List files which should be removed but are not cleaned by the dh_auto_clean command.
See dh_auto_clean(1) and dh_clean(1).
Set the debhelper compatibility level (currently, “9”).
See “COMPATIBILITY LEVELS” in debhelper(8).
No need for this file under “compat >= 3” since all files in the etc/ directory are conffiles.
See dh_installdeb(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 to not be conffiles, keeping the dpkg command happy and quiet.
Installed into the etc/cron/hourly/binarypackage file in binarypackage.
See dh_installcron(1) and cron(8).
Installed into the etc/cron/daily/binarypackage file in binarypackage.
See dh_installcron(1) and cron(8).
Installed into the etc/cron/weekly/binarypackage file in binarypackage.
See dh_installcron(1) and cron(8).
Installed into the etc/cron/monthly/binarypackage file in binarypackage.
See dh_installcro*(1) and cron(8).
Installed into the etc/cron.d/binarypackage file in binarypackage.
See dh_installcron(1), cron(8), and crontab(5).
If this exists, it is installed into etc/default/binarypackage in binarypackage.
See dh_installinit(1).
List directories to be created in binarypackage.
See 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 provided by the doc-base package.
List documentation files to be installed in binarypackage.
See dh_installdocs(1).
Installed into usr/lib/emacsen-common/packages/compat/binarypackage in binarypackage.
See dh_installemacsen(1).
Installed into usr/lib/emacsen-common/packages/install/binarypackage in binarypackage.
See dh_installemacsen(1).
Installed into usr/lib/emacsen-common/packages/remove/binarypackage in binarypackage.
See dh_installemacsen(1).
Installed into usr/lib/emacsen-common/packages/startup/binarypackage in binarypackage.
See dh_installemacsen(1).
List example files or directories to be installed into usr/share/doc/binarypackage/examples/ in binarypackage.
See dh_installexamples(1).
If this exists, it functions as the configuration file for the gbp command.
See gbp.conf(5), gbp(1), and git-buildpackage(1).
List info files to be installed in binarypackage.
See dh_installinfo(1).
Installed into etc/init.d/binarypackage in binarypackage.
See dh_installinit(1).
List files which should be installed but are not installed by the dh_auto_install command.
See dh_install(1) and dh_auto_install(1).
These are copyright file examples generated by the debmake command. Use these as the reference for making copyright file.
Please make sure to erase these files.
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 the whitespace.
See dh_link(1).
Installed into usr/share/lintian/overrides/binarypackage in the package build directory. This file is used to suppress erroneous lintian diagnostics.
See dh_lintian(1) and lintian(1).
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 manpage, use manpage.asciidoc or manpage.1 as the starting point.
List man pages to be installed.
See dh_installman(1).
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.
See dh_installchangelogs(1).
Collection of -p1 patch files which are applied to the upstream source before building the source.
See dpkg-source(8), Section 3.4, “quilt” and Section 4.8, “Alternative: patch files”.
No patch files are generated by the debmake command.
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 of the “Debian Policy Manual”.
See also debconf-devel(7) and 3.9.1 Prompting in maintainer scripts of the “Debian Policy Manual”.
Installed into the first binary package listed in the debian/control file as usr/share/doc/binarypackage/README.Debian.
See dh_installdocs(1).
This file provides the information specific to the Debian package.
If this exists, it is installed into lib/systemd/system/binarypackage.service in binarypackage.
See dh_systemd_enable(1), dh_systemd_start(1), and dh_installinit(1).
The Debian package format.
Use “3.0 (native)” to make this native package
See “SOURCE PACKAGE FORMATS” in dpkg-source(8).
These files are not installed, but will be scanned by the lintian command to provide overrides for the source package.
See dh_lintian(1) and lintian(1).
This is not included in the generated source package but committed to the VCS for its smooth operation.
See “FILE FORMATS” in dpkg-source(8).
See the dpkg-source(1) manpage under "FILE FORMATS" to learn about the package formats and the patch mechanisms.
See “FILE FORMATS” in dpkg-source(8).
The symbols files, if present, are passed to the dpkg-gensymbols command to be processed and installed.
See dh_makeshlibs(1) and Section 5.17, “Library symbols”..
Installed into the first binary package listed in the debian/control file as usr/share/doc/binarypackage/TODO.Debian.
See dh_installdocs(1).
If this exists, it is installed into usr/lib/tmpfiles.d/binarypackage.conf in binarypackage.
See dh_systemd_enable(1), dh_systemd_start(1), and dh_installinit(1).
If this exists, it is installed into etc/init/package.conf in the package build directory.
See dh_installinit(1) and Section 8.1, “Cherry-pick templates”.
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 Section 5.11, “signing-key.pgp”).
See Section 5.9, “DFSG” and uscan(1).
Here are a few reminders to the above list.
Some packages are signed by the GPG key.
For example, GNU hello can be downloaded via HTTP from http://ftp.gnu.org/gnu/hello/ . There are sets of files:
Let’s pick the latest version set.
$ wget http://ftp.gnu.org/gnu/hello/hello-2.9.tar.gz ... $ wget http://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 from the mailing list, use it as the debian/upstream/signing-key.pgp 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
![]() |
Tip |
---|---|
If your network environment blocks access to the HPK port 11371, use “hkp://keyserver.ubuntu.com:80” instead. |
After confirming the key ID 80EE4A00 is trust worthy one, download its public key into the debian/upstream/signing-key.pgp file.
$ gpg --armor --export 80EE4A00 >debian/upstream/signing-key.pgp
Then set the corresponding debian/watch file as follows.
version=3 pgpsigurlmangle=s/$/.sig/ http://ftp.gnu.org/gnu/hello/ hello-(\d[\d.]*)\.tar\.(?:gz|bz2|xz)
Now the uscan command will check the authenticity of the package using the GPG signature.
Some upstream sources do not behave well and you may need to add customization to the build system of those upstream sources.
The package should be customized by the least invasive way to address the root cause of the Debian packaging problem. Your packaging shall be more robust for the future upgrades in this way. (You should also solve the root cause of the problem and send its patch to the upstream.)
Here, there are a few technical approaches to customize the build system:
The customization to the Debian package build system can be done through the debian/rules file.
Add customized configuration files for the dh_* command from the debhelper package in the debian/ directory.
Modifications to the upstream source before building it can be done by placing the collection of the -p1 patches in the patches/ directory and applying them in sequence defined in the patches/series file.
There are several methods to prepare the required -p1 patches for this.
Wherever these patches come from, it is good idea to tag them with DEP-3 compatible header.
These patches should apply cleanly. For new upstream releases, you must normalize them by the dquilt command (see Section 3.4, “quilt”).
$ while dquilt push; do dquilt refresh ; done $ dquilt pop -a
![]() |
Caution |
---|---|
Don’t forget to normalize patches when you upgrade to the new upstream source or import the externally generated patches. |
See Section 4.8, “Alternative: patch files” for example.
Upstream build systems are designed to go through several steps to install generated binary files to the system from the source distribution.
Autotools (autoconf + automake) has 4 steps.
The upstream usually performs the step 1 and builds the upstream tarball for distribution using the “make dist” command. (The generated tarball contains not only the pristine upstream VCS contents but also other generated files.)
The package maintainer needs to take care steps 2 to 4 at least. This is realized by the “dh $@ --with autotools-dev” command used in the debian/rules file.
The package maintainer may wish to take care all steps 1 to 4. This is realized by the “dh $@ --with autoreconf” command used in the debian/rules file. This rebuilds all auto-generated files to the latest version ones and provides better supports for the porting to the newer architectures.
If you wish to learn more on the Autotools, please see:
CMake has 4 steps.
The upstream tarball contains no auto-generated files and is generated by the tar command after the step 1.
The package maintainer needs to take care steps 2 to 4.
If you wish to learn more on the CMake, please see:
Python distutils has 3 steps.
The upstream usually performs the step 1 and builds the upstream tarball for distribution using the “python setup.py sdist” command.
The package maintainer needs to take care the step 2. This is realized simply by the “dh $@” command used in the debian/rules file, after jessie.
The situation of other build systems, such as CMake, are very similar to this Python one.
If you wish to learn more on the Python3 and distutils, please see:
The Debian package is built with the debugging information but packaged into the binary package after stripping the debugging information as required by Chapter 10 - Files of the “Debian Policy Manual”.
The debugging information is automatically packaged separately as the debug package using the dh_strip command in its default. The name of such debug package normally has the -dbgsym suffix.
The debugging information can be packaged separately as the debug package using the “dh_strip --dbg-package=package” command in the override_dh_strip: target of the debian/rules file. The name of such debug package normally has the -dbg suffix.
The installation path of the debugging information is as follows to enable auto-loading of it by the gdb command.
![]() |
Note |
---|---|
The creation of the -dbg package is optional. |
![]() |
Note |
---|---|
Debian will provide some automatic mechanism to provide the debugging information in near future. |
See
Packaging the library software requires you to perform much more work than usual. Here are some reminders for packaging the library software:
Before packaging the shared library software, see:
For the historic background study, see:
Escaping the Dependency Hell [17]
Debian Library Packaging guide [18]
The multiarch support for cross-architecture installation of binary packages (particularly i386 and amd64, but also other combinations) in the dpkg and apt packages introduced to Debian wheezy (7.0, May 2013) demands us to pay extra attention for the packaging.
You should read the following references in detail.
Ubuntu wiki (upstream)
Debian wiki (Debian situation)
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 used in override_dh_* target scripts must be explicitly set in the debian/rules by the maintainer. The <triplet> value is stored in $(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 Section 5.4.4, “Variables for debian/rules” and dpkg-architecture.
Debian policy requires to follow 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 Filesystem Hierarchy Standard to use /usr/lib/<triplet>/ instead of /usr/lib<qual>/ (e.g., /lib32/ and /lib64/) to support the multiarch library.
Table 5.1. The multiarch library path options
Classic path | i386 multiarch path | amd64 multiarch path |
---|---|---|
/lib/ |
/lib/i386-linux-gnu/ |
/lib/x86_64-linux-gnu/ |
/usr/lib/ |
/usr/lib/i386-linux-gnu/ |
/usr/lib/x86_64-linux-gnu/ |
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.
All files installed simultaneously as the multiarch package to the same file path should have exactly the same file content. You must be careful on differences generated by the data byte order and by the compression algorithm.
![]() |
Note |
---|---|
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, 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 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 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 the shared library files in the other path, GCC option -l must be set by the pkg-config command to make them loaded properly.
GCC includes both /usr/include/ and /usr/include/<triplet>/ by default on the multiarch Debian system.
If the header file is not in those paths, GCC option -I must be set by the pkg-config command to make "#include <foo.h>" work properly.
Table 5.2. The multiarch header file path options
Classic path | i386 multiarch path | amd64 multiarch path |
---|---|---|
/usr/include/ |
/usr/include/i386-linux-gnu/ |
/usr/include/x86_64-linux-gnu/ |
/usr/include/ packagename / |
/usr/include/i386-linux-gnu/ packagename / |
/usr/include/x86_64-linux-gnu/ packagename / |
/usr/lib/i386-linux-gnu/ packagename / |
/usr/lib/x86_64-linux-gnu/ packagename / |
The use if the /usr/lib/<triplet>/packagename/ path for the header files allows the upstream to use the same install script for the multiatch system with /usr/lib/<triplet> and the biarch system with /usr/lib<qual>/. [19]
The use of the file path containing packagename enables to have more than 2 development libraries simultaneously installed on a system.
The pkg-config program is used to retrieve information about installed libraries in the system. It stores its configuration parameters in the *.pc file and is used for setting the -I and -l options for GCC.
Table 5.3. The *.pc file path options
Classic path | i386 multiarch path | amd64 multiarch path |
---|---|---|
/usr/lib/pkgconfig/ |
/usr/lib/i386-linux-gnu/pkgconfig/ |
/usr/lib/x86_64-linux-gnu/pkgconfig/ |
The symbols support in the dpkg introduced to 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 to each symbol.
The 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.
Copy it to the debian/binarypackage.symbols file.
Build the binary package.
If the dpkg-gensymbols command warns some new symbols:
If the dpkg-gensymbols command does not warn new symbols:
For the details, you should read the following primary references.
Yous should also check:
![]() |
Tip |
---|---|
For C++ libraries and other cases where the tracking of the 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 compiler hardening support spreading for Debian jessie (8.0, TBA) demands us to pay extra attention for 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 Chapter 4, Simple Example and dpkg-buildflags(1)).
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-control → usr/share/bug/binarypackage/control
debian/binarypackage.bug-presubj → usr/share/bug/binarypackage/presubj
debian/binarypackage.bug-script → usr/share/bug/binarypackage or usr/share/bug/binarypackage/script
See dh_bugfiles(1) and reportbug’s Features for Developers
The debconf package enables us to configure packages during their installation in 2 main ways:
interactively from the menu interface (dialog, gnome, kde, …)
All user interactions for the package installation must be handled by this debconf system using the following files.
debian/binarypackage.cofig
debian/binarypackage.template
package configuration scripts
See dh_installdebconf(1), debconf(7), debconf-devel(7) and 3.9.1 Prompting in maintainer scripts of the “Debian Policy Manual”.
DEP-8 defines the debian/tests/control file as the RFC822-style test metadata file for the 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 adt-run command provided by the autopkgtest package 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.
[11] 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.
[12] Use of the “debameke -t …” command can help this workflow. See Section 6.2, “Upstream snapshot (-d, -t)”.
[13] This simplicity is available since the version 7 of the debhelper package. This guide assumes the use of the debhelper version 9 or newer.
[14] The debmake command generates a bit more complicated debian/rules file. But this is the core part.
[15] If you are using the vim editor, make sure to save this with the “:wq” command.
[16] The licensecheck command from the devscripts package was referenced to make this internal checker.
[17] This document was written before the introduction of the symbols file.
[18] The strong preference to use the SONAME versioned -dev package names over the single -dev package name in its Chapter 6. Development (-DEV) packages 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.
[19] This path is compliant to 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."