Chapter 6. debmake options

Table of Contents

6.1. Shortcut options (-a, -i)
6.1.1. Python module
6.2. Upstream snapshot (-d, -t)
6.3. Upstream snapshot (alternative git deborig approach)
6.4. debmake -cc
6.5. debmake -k
6.6. debmake -j
6.7. debmake -x
6.8. debmake -P
6.9. debmake -T

Here are some notable options for the debmake command.

The debmake command offers 2 shortcut options.

  • -a : open the upstream tarball
  • -i : execute script to build the binary package

The example in the above Chapter 4, Simple Example can be done simply as follows.

 $ debmake -a package-1.0.tar.gz -i debuild
[Tip] Tip

A URL such as “” may be used for the -a option.

[Tip] Tip

A URL such as “” may be used for the -a option, too.

This packaging scheme is good for the git repository organized as described in gbp-buildpackage(7) which uses the master, upstream, and pristine-tar branches.

The upstream snapshot from the upstream source tree in the VCS can be made with the -d option if the upstream package supports the “make dist” equivalence.

 $ cd /path/to/upstream-vcs
 $ debmake -d -i debuild

Alternatively, the same can be made with the -t option if the upstream tarball can be made with the tar command.

 $ cd /path/to/upstream-vcs
 $ debmake -p package -t -i debuild

Unless you provide the upstream version with the -u option or with the debian/changelog file, a snapshot upstream version is generated in the 0~%y%m%d%H%M format, e.g., 0~1403012359, from the UTC date and time.

If the upstream VCS is hosted in the package/ directory instead of the upstream-vcs/ directory, the “-p package” can be skipped.

If the upstream source tree in the VCS contains the debian/* files, the debmake command with either the -d option or the -t option combined with the -i option automates the making of a non-native Debian package from the VCS snapshot while using these debian/* files.

 $ cp -r /path/to/package-0~1403012359/debian/. /path/to/upstream-vcs/debian
 $ dch
   ... update debian/changelog
 $ git add -A .; git commit -m "vcs with debian/*"
 $ debmake -t -p package -i debuild

This non-native Debian binary package building scheme using the “debmake -t -i debuild” command may be considered as the quasi-native Debian package scheme since the packaging situation resembles the native Debian binary package building case using the debuild command without the upstream tarball.

Use of a non-native Debian package helps to ease communication with the downstream distros such as Ubuntu for bug fixes etc.

This packaging scheme is good for the git repository organized as described in dgit-maint-merge(7) which uses the master branch only.

You can create the upstream tarball and Debian package simply as follows.

 $ cd /path/to/upstream-git
 $ git deborig -f HEAD
 $ pdebuild

This scheme can be applied to the quasi-native Debian package scheme when debian/changelog contains the non-native version number with revision like 0.16-1.

For -1 revision, this use of git-deborig(1) as above is how this debmake-doc package generates the upstream tarball. For source format 3.0 (quilt), files under debian/ directory in the upstream tarball has no negatives. You may override the lintian warning.

For -2, -3, … revisions, you need to fetch and use the uploaded upstream tarball instead. For this, origtargz(1) may be handy.

The debmake command with the -cc option can make a summary of the copyright and license for the entire source tree to standard output.

 $ tar -xvzf package-1.0.tar.gz
 $ cd package-1.0
 $ debmake -cc | less

With the -c option, this provides shorter report.

When updating a package for the new upstream release, the debmake command can verify the content of the existing debian/copyright file against the copyright and license situation of the entire updated source tree.

 $ cd package-vcs
 $ gbp import-orig --uscan --pristine-tar
 ... update source with the new upstream release
 $ debmake -k | less

The “debmake -k” command parses the debian/copyright file from the top to the bottom and compares the license of all the non-binary files in the current package with the license described in the last matching file pattern entry of the debian/copyright file.

When editing the auto-generated debian/copyright file, please make sure to keep the generic file patterns at the top of the list.

[Tip] Tip

For all new upstream releases, run the “debmake -k” command to ensure that the debian/copyright file is current.

The generation of a functioning multi-binary package always requires more manual work than that of a functioning single binary package. The test build of the source package is the essential part of it.

For example, let’s package the same package-1.0.tar.gz (see Chapter 4, Simple Example) into a multi binary package.

  • Invoke the debmake command with the -j option for the test building and the report generation.

     $ debmake -j -a package-1.0.tar.gz
  • Check the last lines of the file to judge build dependencies for Build-Depends. (You do not need to list packages used by debhelper, perl, or fakeroot explicitly in Build-Depends. This technique is useful for the generation of a single binary package, too.)
  • Check the contents of the package.install.log file to identify the install paths for files to decide how you split them into multiple packages.
  • Start packaging with the debmake command.

     $ rm -rf package-1.0
     $ tar -xvzf package-1.0.tar.gz
     $ cd package-1.0
     $ debmake -b"package1:type1, ..."
  • Update debian/control and debian/binarypackage.install files using the above information.
  • Update other debian/* files as needed.
  • Build the Debian package with the debuild command or its equivalent.

     $ debuild
  • All binary package entries specified in the debian/binarypackage.install file are generated as binarypackage_version-revision_arch.deb.
[Note] Note

The -j option for the debmake command invokes dpkg-depcheck(1) to run debian/rules under strace(1) to obtain library dependencies. Unfortunately, this is very slow. If you know the library package dependencies from other sources such as the SPEC file in the source, you may just run the "debmake …" command without the -j option and run the “debian/rules install” command to check the install paths of the generated files.

The amount of template files generated by the debmake command depends on the -x[01234] option.

[Note] Note

None of the existing configuration files are modified by the debmake command.

The debmake command invoked with the -P option pedantically checks auto-generated files for copyright+license text even if they are with permissive license.

This option affects not only the content of the debian/copyright file generated by normal execution, but also the output by the execution with the -k, -c, -cc, and -ccc options.

The debmake command invoked with the -T option additionally prints verbose tutorial comment lines. The lines marked with ### in the template files are part of the verbose tutorial comment lines.