Here are some additional explantion for debmake options.

15.1. Shortcut options (-a, -i)

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 5, Simple packaging” can be done simply as follows.

 $ debmake -a package-1.0.tar.gz -i debuild

	Tip
	A URL such as “https://www.example.org/DL/package-1.0.tar.gz” may be used for the -a option.

	Tip
	A URL such as “https://arm.koji.fedoraproject.org/packages/ibus/1.5.7/3.fc21/src/ibus-1.5.7-3.fc21.src.rpm” may be used for the -a option, too.

15.2. debmake -b

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: (e.g. amd64)

Multi-Arch: (see “Section 9.10, “Multiarch””)
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. 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)
python3: Python (version 3) script package (all, foreign) (alias: py3, python, py)
ruby: Ruby script package (all, foreign) (alias: rb)
nodejs: Node.js based JavaScript package (all, foreign) (alias: js)
script: Shell and other interpretted language 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.

Here are examples for typical binary package split scenarios where the upstream Debian source package name is foo:

Generating an executable binary package foo:
- “-b’foo:bin'”, or its short form `-b'-'`", or no -b option
Generating an executable (python3) binary package python3-foo:
- “-b’python3-foo:py'”, or its short form “-b’python3-foo'”
Generating a data package foo:
- “-b’foo:data'”, or its short form “-b'-:data'”
Generating a executable binary package foo and a documentation one foo-doc:
- “-b’foo:bin,foo-doc:doc'”, or its short form “-b'-:-doc'”
Generating a executable binary package foo, a library package libfoo1, and a library development package libfoo-dev:
- “-b’foo:bin,libfoo1:lib,libfoo-dev:dev'” or its short form “-b'-,libfoo1,libfoo-dev'”

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

15.3. debmake -cc

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.

15.4. Snapshot upstream tarball (-d, -t)

This test building 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 upstream VCS can be made with the -d option if the upstream 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 without the real upstream tarball is considered as the quasi-native Debian package. See “Section 10.13, “Quasi-native Debian packaging””.

15.5. debmake -j

This is an experimental feature.

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 5, Simple packaging”) 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 package.build-dep.log 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

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.

15.6. debmake -k

This is an experimental feature.

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
	For all new upstream releases, run the “debmake -k” command to ensure that the debian/copyright file is current.

See “Section 13.1, “Cherry-pick templates”” for cherry-picking of the template files.

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

Chapter 15. debmake options