This guide may be used under the terms the GNU General Public License version 2 or higher.

This guide was made using the following previous documents as its reference:

  • “Making a Debian Package (AKA the Debmake Manual)”, copyright © 1997 Jaldhar Vyas.

  • “The New-Maintainer’s Debian Packaging Howto”, copyright © 1997 Will Lowe.

  • “Debian New Maintainers' Guide”, copyright © 1998-2002 Josip Rodin, 2005-2014 Osamu Aoki, 2010 Craig Small, and 2010 Raphaël Hertzog.

Newer versions of this guide should always be available in the debmake package.

A short tutorial of the debmake command for the experienced Debian maintainer is available as Debmake tutorial.

Preface

If you are a somewhat experienced Debian user
[You do need to know a little about Unix programming but you certainly don’t need to be a wizard. You can learn about the basic handling of a Debian system from the Debian Reference. It contains some pointers to learn about Unix programming, too.]
, you may have encountered following situations:

  • You wish to install a certain software package not yet found in the Debian archive.

  • You wish to update a Debian package with the newer upstream release.

  • You wish to fix bugs of a Debian package with some patches.

If you wanted to create a Debian package to fulfill these wishes and to share your work with the community, you are the target audience of this guide as a prospective Debian maintainer.
[If you are not interested in sharing the Debian package, you can certainly work around your local situation by compiling and installing the fixed upstream source package into /usr/local/.]
 Welcome to the Debian community.

Debian has many social and technical rules and conventions to follow since it is a large volunteer organization with history. Debian also has developed huge array of packaging tools and archive maintenance tools to build consistent set of binary packages addressing many technical objectives:

  • clean build under clearly specified package dependencies and patches

  • packages build across many architectures

  • optimal splits into multiple binary packages

  • smooth library transitions

  • security enhancement using specific compiler flags

  • multiarch support

  • …

These make it somewhat overwhelming for many new prospective Debian maintainers to get involved with Debian. This guide tries to provide entry points for them to get started. It describes as follows:

  • What you should know before getting involved with Debian as a prospective maintainer.

  • What it looks like to make a simple Debian package.

  • What kind of rules exist for making the Debian package.

  • Tips for making the Debian package.

  • Examples of making Debian packages for several typical scenarios.

The author felt limitations of updating the original “New Maintainers' Guide” with the dh-make package and decided to create an alternative tool and its matching document to address modern needs for the maintainers. The result is the debmake package and this “Maintainers' Guide”.

Many chores and tips have been integrated into the debmake command making the description of the Debian packaging simple. This allowed this document to offer more examples which were not available in the “New Maintainers' Guide”.

Caution
 It takes many hours to properly create and maintain Debian packages. The Debian maintainer must be both technically competent and diligent to take up this challenge.

Some important topics are explained in detail. Some of them may look irrelevant to you. Please be patient. Some corner cases are skipped. Some topics are only covered by the external pointers. These are intentional choices to keep this guide simple and maintainable.

Prerequisites

Here are the prerequisites which you need to understand before you to get involved with Debian.

People around Debian

There are several types of people interacting around Debian with different roles:

  • upstream author: the person who made the original program.

  • upstream maintainer: the person who currently maintains the program.

  • maintainer: the person making the Debian package of the program.

  • sponsor: a person who helps maintainers to upload packages to the official Debian package archive (after checking their contents).

  • mentor: a person who helps novice maintainers with packaging etc.

  • Debian Developer (DD): a member of the Debian project with full upload rights to the official Debian package archive.

  • Debian Maintainer (DM): a person with limited upload rights to the official Debian package archive.

Please note that you cannot become an official Debian Developer (DD) overnight, because it takes more than technical skill. Please do not be discouraged by this. If it is useful to others, you can still upload your package either as a maintainer through a sponsor or as a Debian Maintainer.

Please note that you do not need to create any new package to become an official Debian Developer. Contributing to the existing packages can provide a path to becoming an official Debian Developer too. There are many packages waiting for good maintainers (see [approaches]).

How to contribute

Please refer to the following to learn how to contribute to Debian:

Social dynamics of Debian

Please understand Debian’s social dynamics to prepare yourself for interactions with Debian:

  • We all are volunteers.

    • You cannot impose on others what to do.

    • You should be motivated to do things by yourself.

  • Friendly cooperation is the driving force.

    • Your contribution should not over-strain others.

    • Your contribution is valuable only when others appreciate it.

  • Debian is not your school where you get automatic attention of teachers.

    • You should be able to learn many things by yourself.

    • Attention from other volunteers is a very scarce resource.

  • Debian is constantly improving.

    • You are expected to make high quality packages.

    • You should adapt yourself to change.

Since we focus only on the technical aspects of the packaging in the rest of this guide, please refer to the following to understand the social dynamics of Debian:

Technical reminders

Here are some technical reminders to accommodate other maintainers to work on your package easily and effectively to maximize the output of Debian as a whole.

  • Make your package easy to debug.

    • Keep your package simple.

    • Don’t over-engineer your package.

  • Keep your package well-documented.

    • Use readable code style.

    • Make comments in code.

    • Format code consistently.

    • Maintain the git repository
      [The overwhelming number of Debian maintainers use git over other VCS systems such as hg, bzr, etc.]
       of the package.

Note
 Debugging of software tends to consume more time than writing the initial working software.

Debian documentation

Please make yourself ready to read the pertinent part of the official Debian documentation together with this guide as needed to generate perfect Debian packages:

If this guide contradicts with the official Debian documentation, they are correct. Please file a bug report on the debmake package using the reportbug command.

Here are alternative tutorial documents which you may read along with this guide:

Help resources

Before you decide to ask your question in some public place, please do your part of efforts, i.e., read the fine documentation:

Your desired information can be found effectively by using the well formed search string such as "keyword site:lists.debian.org" to limit the search domain of the web search engine.

Making a small test package is a good way to learn details of the packaging. Inspecting existing well maintained packages is the best way to learn how other people make packages.

If you still have questions about the packaging, you can ask them interactively:

The more experienced Debian developers will gladly help you, if you ask properly after making your required efforts.

Archive situation

Please realize the situation of the Debian archive.

  • Debian already has packages for most kinds of programs.

  • The number of packages already in the Debian archive is several tens of times greater than that of active maintainers.

  • Unfortunately, some packages lack appropriate level of attention by the maintainer.

Thus, contributions to packages already in the archive are far more appreciated (and more likely to receive sponsorship for the uploading) by other maintainers.

Tip
 The wnpp-alert command from the devscripts package can check for installed packages up for adoption or orphaned.

Contribution approaches

Here is a pseudo-Python code for your contribution approaches to Debian with a program:

  • if exist_in_debian(program):

    • if is_team_maintained(program):

      • join_team(program)

    • if is_orphaned(program) : # maintainer: Debian QA Group

      • adopt_it(program)

    • elif is_RFA(program) : # Request for Adoption

      • adopt_it(program)

    • else:

      • if need_help(program):

        • contact_maintainer(program)

        • triaging_bugs(program)

        • preparing_QA_or_NMU_uploads(program)

      • else:

        • leave_it(program)

  • else: # new packages

    • if not is_good_program(program):

      • give_up_packaging(program)

    • elif not is_it_distributable(program):

      • give_up_packaging(program)

    • else: # worth packaging

      • if is_ITPed_by_others(program):

        • if need_help(program):

          • contact_ITPer_for collaboration(program)

        • else:

          • leave_it(program)

      • else: # really new

        • if is_there_team(program):

          • join_team(program)

        • if is_it_DSFG(program) and is_its_dependency_DFSG(program):

          • file_ITP(program, area="main") # This is Debian.

        • elif is_it_DSFG(program):

          • file_ITP(program, area="contrib") # This is not Debian.

        • else: # non-DFSG

          • file_ITP(program, area="non-free") # This is not Debian.

        • package_it_and_close_ITP(program)

Here:

You either need to file an ITP or adopt a package to start working on it. See the “Debian Developer’s Reference”:

novice maintainer

The novice maintainer should avoid packaging programs with the high security exposure:

  • setuid or setgid program

  • daemon program

  • program installed in the /sbin/ or /usr/sbin/ directories

When you gain more experience in packaging, you’ll be able to package such programs.

Tool Setups

The build-essential package must be installed in the build environment.

The devscripts package should be installed on the maintainer environment.

Although this is not necessary the absolute requirement, it is a good idea to install and setup all of the popular set of packages mentioned in this chapter on the maintainer environment. This enables us to share the common baseline working environment.

Please install the tools mentioned in the Overview of Debian Maintainer Tools of the “Debian Developer’s Reference”, as needed, too.

Caution
 Tool setups presented here are only meant as an example and may not be up-to-date with the latest packages on the system. Debian development is a moving target. Please make sure to read the pertinent documentation and update the configuration as needed.

Email address

Various Debian maintenance tools recognize your email address and name to use by the shell environment variables $DEBEMAIL and $DEBFULLNAME.

Let’s setup these packages by adding the following lines to ~/.bashrc
[This assumes you are using Bash as your login shell. If you use some other login shell such as Z shell, use their corresponding configuration files instead of ~/.bashrc.]
.

Add to the ~/.bashrc file
DEBEMAIL="your.email.address@example.org"
DEBFULLNAME="Firstname Lastname"
export DEBEMAIL DEBFULLNAME

mc

The mc command offers very easy ways to manage files. It can open the binary deb file to check its content by pressing the Enter key over the binary deb file. It uses the dpkg-deb command as its back-end. Let’s setup it to support easy chdir as follows.

Add to the ~/.bashrc file
# mc related
export HISTCONTROL=ignoreboth
. /usr/lib/mc/mc.sh

git

Nowadays, the git command is the essential tool to manage the source tree with history.

You may wish to set several global configuration in ~/.gitconfig such as your name and email address used by Git by the following.

$ git config --global user.name "Name Surname"
$ git config --global user.email yourname@example.com

If you are too accustomed to the CVS or Subversion commands, you may wish to set several command aliases by the following.

$ git config --global alias.ci "commit -a"
$ git config --global alias.co checkout

You can check your global configuration by the following.

$ git config --global --list
Tip
 It is essential to use the gitk command to work effectively with the history of the Git repository.

quilt

The quilt command offers a basic method for recording modifications. For the Debian packaging, it should be customized to record modifications in the debian/patches/ directory instead of its default patches/ directory.

In order to avoid changing the behavior of the quilt command itself, let’s create an alias dquilt for the Debian packaging by adding the following lines to the ~/.bashrc file. The second line provides the same shell completion feature of the quilt command to the dquilt command.

Add to the ~/.bashrc file
alias dquilt="quilt --quiltrc=${HOME}/.quiltrc-dpkg"
complete -F _quilt_completion $_quilt_complete_opt dquilt

Then let’s create ~/.quiltrc-dpkg as follows.

d=.
while [ ! -d $d/debian -a `readlink -e $d` != / ];
    do d=$d/..; done
if [ -d $d/debian ] && [ -z $QUILT_PATCHES ]; then
    # if in Debian packaging tree with unset $QUILT_PATCHES
    QUILT_PATCHES="debian/patches"
    QUILT_PATCH_OPTS="--reject-format=unified"
    QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto"
    QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index"
    QUILT_COLORS="diff_hdr=1;32:diff_add=1;34:" + \
            "diff_rem=1;31:diff_hunk=1;33:diff_ctx=35:diff_cctx=33"
    if ! [ -d $d/debian/patches ]; then mkdir $d/debian/patches; fi
fi

See quilt(1) and How To Survive With Many Patches or Introduction to Quilt on how to use the quilt command.

See [modpkg] for example usages.

devscripts

The debsign command, included in the devscripts package, is used to sign the Debian package with your private GPG key.

The debuild command, included in the devscripts package, builds the binary package and check them with the lintian command. It is useful to have verbose outputs from the lintian command.

You can setup these by the ~/.devscripts as follows.

DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -us -uc"
DEBUILD_LINTIAN_OPTS="-i -I --show-overrides"
DEBSIGN_KEYID="Your_GPG_keyID"

Currently, RSA key with 4096 bits is good idea. See Creating a new GPG key.

pbuilder

The pbuilder package provides the clean room (chroot) build environment.
[The sbuild package provides an alternative chroot platform.]

Let’s customize it with several helper packages.

  • The cowbuilder package to boost the chroot creation speed.

  • The eatmydata package to boost the dpkg speed.

  • The ccache package to boost the gcc speed.

  • The parallel make to boost the build speed.

  • The lintian package to find bugs in the package.

  • The bash, mc, and vim packages in case build fails.

Let’s create ~/.pbuilderrc as follows.

AUTO_DEBSIGN="${AUTO_DEBSIGN:-no}"
PDEBUILD_PBUILDER=cowbuilder
HOOKDIR="/var/cache/pbuilder/hooks"
#MIRRORSITE=" http://ftp.us.debian.org/debian/"
MIRRORSITE="http://cdn.debian.net/debian/"
#APTCACHE=/var/cache/pbuilder/aptcache
APTCACHE=/var/cache/apt/archives
#BUILDRESULT=/var/cache/pbuilder/result/
BUILDRESULT=../
EXTRAPACKAGES="ccache lintian eatmydata"
# enable eatmydata for pbuilder
if [ -z "$LD_PRELOAD" ]; then
  LD_PRELOAD=/usr/lib/libeatmydata/libeatmydata.so
else
  LD_PRELOAD="$LD_PRELOAD":/usr/lib/libeatmydata/libeatmydata.so
fi
export LD_PRELOAD
# enable ccache for pbuilder
export PATH="/usr/lib/ccache:${PATH}"
export CCACHE_DIR="/var/cache/pbuilder/ccache"
BINDMOUNTS="${CCACHE_DIR}"
# parallel make
DEBBUILDOPTS=-j8
Note
 The parallel make may fail for some existing packages.

Let’s create a hook scripts as follows.

/var/cache/pbuilder/hooks/A10ccache

#!/bin/sh
set -e
# increase the ccache caching size
ccache -M 4G
# output the current statistics
ccache -s

/var/cache/pbuilder/hooks/B90lintian

#!/bin/sh
set -e
apt-get -y --force-yes install lintian
echo "+++ lintian output +++"
su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes; :" -l pbuilder
echo "+++ end of lintian output +++"

/var/cache/pbuilder/hooks/C10shell

#!/bin/sh
set -e
apt-get -y --force-yes install vim bash mc
# invoke shell if build fails
cd /tmp/buildd/*/debian/..
/bin/bash < /dev/tty > /dev/tty 2> /dev/tty
Note
 All these scripts need to be set world executable: -rwxr-xr-x 1 root root.
Note
 The ccache cache directory /var/cache/pbuilder/ccache needs to be set world writable: -rwxrwxrwx 1 root root for the pbuilder command. You should be aware of associated security concerns.

git-buildpackage

You may wish to set several global configuration in ~/.gbp.conf

# Configuration file for "gbp <command>"

[DEFAULT]
# the default build command:
builder = git-pbuilder -i -I -us -uc
# use pristine-tar:
pristine-tar = True
# Use color when on a terminal, alternatives: on/true, off/false or auto
color = auto
Tip
 The gbp command is the alias of the git-buildpackage command.

HTTP proxy

You should set up local HTTP caching proxy to save the bandwidth for the Debian package repository access. There are several choices:

  • Simple HTTP caching proxy using the squid package.

  • Specialized HTTP caching proxy using the apt-cacher-ng package.

Private Debian repository

You can set up a private Debian package repository with the reprepro package.

Simple Debian package

There is an old Latin saying: “Longum iter est per praecepta, breve et efficax per exempla” (“It’s a long way by the rules, but short and efficient with examples”).

Let’s start with an example of creating a simple Debian package.

hello-c

Let’s consider a simple C source hello-c with the upstream version 1.0 following the $(DESTDIR) feature of the GNU Coding Standards and FHS for the file installation path as an example.

The C source hello.c is a very simple one.

 $ cat hello-c-1.0/hello.c
#include <stdio.h>
int
main()
{
        printf("Hello, Debian packager!\n");
        return 0;
}

Makefile supports $(DESTDIR) and FHS.

 $ cat hello-c-1.0/Makefile
all: hello

hello: hello.c
        gcc -Wall -o hello hello.c

install: hello
        install -D hello $(DESTDIR)/usr/bin/hello

clean:
        -rm -f hello

distclean: clean

.PHONY: all install clean distclean

hello-c-1.0.tar.gz

Let’s make an upstream tarball hello-c-1.0.tar.gz.

 $ tar -czf hello-c-1.0.tar.gz hello-c-1.0
 $ tree
.
├── hello-c-1.0
│   ├── hello.c
│   └── Makefile
└── hello-c-1.0.tar.gz

1 directory, 3 files

debmake

The debmake command is the helper script for the Debian packaging. Let’s note its 4 most important features.
[See Debmake tutorial for the extensive list of features.]

  • It always sets most of the obvious option states and values to reasonable defaults.

  • It doesn’t overwrite existing configuration files in the debian/ directory.

  • It supports the multiarch package.

  • It creates good template files such as the debian/copyright file complaint to DEP-5.

These 4 features make Debian packaging simple and modern. Let’s use this debmake command.

Big picture

Let’s get the big picture for the making of the Debian package from the upstream tarball hello-c-1.0.tar.gz.

A single non-native Debian binary package can be made with the debmake command as follows.

 $ cd hello-c-1.0
 $ debmake
   ... (skipped)
 $ debuild
Tip
 The debuild command in these examples may be substituted by the equivalent commands such as the pdebuild command.

Since manual adjustments of auto-generated configuration files are skipped, the generated binary package lacks meaningful package description and some of the policy requirements are missed. This package functions well under the dpkg command, and is good enough for your local deployment.

debmake: step-by-step

The output from the debmake command was intentionally skipped in the above. The actual command output is very verbose and explains what it does as follows.

 $ cd hello-c-1.0
 $ debmake
D: /usr/bin/debmake started
D: PYTHONPATH = /usr/bin:/usr/lib/python3.4:/usr/lib/python3.4/plat-x86_64-...
I: set parameters
I: sanity check of parameters
I: pkg="hello-c", ver="1.0", rev="1"
I: *** start packaging in "hello-c-1.0". ***
I: provide hello-c_1.0.orig.tar.gz for non-native Debian package
I: pwd = "/path/to"
I: $ ln -sf hello-c-1.0.tar.gz hello-c_1.0.orig.tar.gz
I: pwd = "/path/to/hello-c-1.0"
I: parse binary package settings:
I: binary package=hello-c Type=bin / Arch=any M-A=foreign
I: analyze the source tree
I: build_type = make
I: scan source for copyright+license text and file extensions
I: 100 %, ext = c
I: check_all_licenses
I: ..
I: check_all_licenses completed for 2 files.
I: bunch_all_licenses
I: format_all_licenses
I: make debian/* template files
I: single binary package
I: debmake -x "1" ...
I: creating => debian/control
I: creating => debian/copyright
I: creating => debian/changelog
I: creating => debian/rules
I: creating => debian/README.Debian
I: creating => debian/compat
I: creating => debian/watch
I: creating => debian/source/format
I: creating => debian/source/local-options
I: creating => debian/patches/series
I: run "debmake -x2" to get more template files
I: $ wrap-and-sort

The debmake command generates all these template files based on the command line option. Since no options are specified, the debmake command choses reasonable default values for you:

  • The source package name: hello-c

  • The upstream version: 1.0

  • The binary package name: hello-c

  • The Debian revision: 1

  • The package type: bin (the ELF binary executable package)

  • The -x option: -x1 (default for the single binary package)

Let’s inspect generated template files.

The debian/rules file is the build script provided by the package maintainer.

debian/rules:
 $ cat debian/rules
#!/usr/bin/make -f
### See debhelper(7) (uncomment to enable)
### This is a autogenerated template for debian/rules.
### You must remove unused comment lines for the released package.
###
### Output every command that modifies files on the build system.
#DH_VERBOSE = 1
###
### Define DEB_HOST_* and  DEB_BUILD_* variables using
### dpkg-architecture(1) if they are used in the override_*
### target scripts.  E.g.:
###DEB_HOST_ARCH_OS = $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
###
### Copy some variable definitions from pkg-info.mk and vendor.mk
### under /usr/share/dpkg/ to here if they are useful.
###
### See FEATURE AREAS in dpkg-buildflags(1)
#export DEB_BUILD_MAINT_OPTIONS = hardening=+all
###
### See ENVIRONMENT in dpkg-buildflags(1)
### Package maintainers to append CFLAGS
#export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
### Package maintainers to append LDFLAGS
#export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

### main packaging script based on dh7 syntax
%:
        dh $@

### debmake generated override targets
### This is example for Cmake (See http://bugs.debian.org/641051 )
###override_dh_auto_configure:
###     dh_auto_configure -- \
###     -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH)

This is essentially the standard debian/rules file with the dh command. (There are some commented out contents for you to customize it.)

Tip
 Configuration files used by the dh_* commands from the debhelper package usually treat # as the start of the comment line.

The debian/control file provides the main meta data for the Debian package.

debian/control:
 $ cat debian/control
Source: hello-c
Section: unknown
Priority: extra
Maintainer: "Firstname Lastname" <email.address@example.org>
Build-Depends: debhelper (>=9)
Standards-Version: 3.9.5
Homepage: <insert the upstream URL, if relevant>

Package: hello-c
Architecture: any
Multi-Arch: foreign
Depends: ${misc:Depends}, ${shlibs:Depends}
Description: auto-generated package by debmake
 This Debian binary package was auto-generated by the
 debmake(1) command provided by the debmake package.
 .
 ===== This comes from the unmodified template file =====
 .
 Please edit this template file (debian/control) and other package files
 (debian/*) to make them meet all the requirements of the Debian Policy
 before uploading this package to the Debian archive.
 .
 See
  * http://www.debian.org/doc/manuals/maint-guide/dreq.en.html#control
  * http://www.debian.org/doc/manuals/developers-reference/best-pkging-prac...
 .
 The synopsis description at the top should be about 60 characters and
 written as a phrase.  No extra capital letters or a final period.  No
 articles — "a", "an", or "the".
 .
 The package description for general-purpose applications should be
 written for a less technical user.  This means that we should avoid
 jargon.  GNOME or KDE is fine but GTK+ is probably not.
 .
 Use the canonical forms of words:
  * Use X Window System, X11, or X; not X Windows, X-Windows, or X Window.
  * Use GTK+, not GTK or gtk.
  * Use GNOME, not Gnome.
  * Use PostScript, not Postscript or postscript.

Since this is the ELF binary executable package, the debmake command sets "Architecture: any" and "Multi-Arch: foreign". Also, it sets required substvar parameters as "Depends: ${shlibs:Depends}, ${misc:Depends}". These are explained in [deb].

Note
 Please note this debian/control file uses the RFC-822 style as documented in 5.2 Source package control files — debian/control of the “Debian Policy Manual”. The use of the empty line and the leading space are significant.

There are several other template files under the debian/ directory. These are explained in [deb].

The source tree after the basic debmake execution.
 $ cd ..
 $ tree
.
├── hello-c-1.0
│   ├── debian
│   │   ├── changelog
│   │   ├── compat
│   │   ├── control
│   │   ├── copyright
│   │   ├── patches
│   │   │   └── series
│   │   ├── README.Debian
│   │   ├── rules
│   │   ├── source
│   │   │   ├── format
│   │   │   └── local-options
│   │   └── watch
│   ├── hello.c
│   └── Makefile
├── hello-c_1.0.orig.tar.gz -> hello-c-1.0.tar.gz
└── hello-c-1.0.tar.gz

4 directories, 14 files

For the proper packaging, you are required to make further modification here.

For learning purpose, let’s leave such details and move on for now.

debuild: step-by-step

You can create a non-native Debian package using the debuild command (or its equivalents) in this source tree. The command output is very verbose and explains what it does as follows.

 $ cd hello-c-1.0
 $ debuild
 dpkg-buildpackage -rfakeroot -D -us -uc -i
 ...
 fakeroot debian/rules clean
dh clean
 ...
 debian/rules build
dh build
 ...
 fakeroot debian/rules binary
dh binary
 ...
Finished running lintian.
Tip
 If you wish a more fine grained build report, please uncomment "#DH_VERBOSE = 1" in the debian/rules file before running the debuild command.

Let’s inspect the result.

The generated files of hello-c version 1.0 by the debuild command:
 $ cd ..
 $ tree -L 1
.
├── hello-c-1.0
├── hello-c_1.0-1_amd64.build
├── hello-c_1.0-1_amd64.changes
├── hello-c_1.0-1_amd64.deb
├── hello-c_1.0-1.debian.tar.xz
├── hello-c_1.0-1.dsc
├── hello-c_1.0.orig.tar.gz -> hello-c-1.0.tar.gz
└── hello-c-1.0.tar.gz

1 directory, 7 files

You see all the generated files.

  • The hello-c_1.0.orig.tar.gz is a symlink to the upstream tarball.

  • The hello-c_1.0-1.debian.tar.xz contains the maintainer generated contents.

  • The hello-c_1.0-1.dsc is the meta data file for the Debian source package.

  • The hello-c_1.0-1_amd64.deb is the Debian binary package.

  • The hello-c_1.0-1_amd64.changes is the meta data file for the Debian binary package.

The hello-c_1.0-1.debian.tar.xz contains the Debian changes to the upstream source as follows.

The compressed archive contents of hello-c_1.0-1.debian.tar.xz:
 $ tar -tJf hello-c_1.0-1.debian.tar.xz
debian/
debian/patches/
debian/patches/series
debian/control
debian/changelog
debian/rules
debian/source/
debian/source/format
debian/README.Debian
debian/compat
debian/watch
debian/copyright
 $ tar -tzf hello-c-1.0.tar.gz
hello-c-1.0/
hello-c-1.0/Makefile
hello-c-1.0/hello.c

The hello-c_1.0-1_amd64.deb contains the files to be installed as follows.

The binary package contents of hello-c_1.0-1_amd64.deb:
 $ dpkg -c hello-c_1.0-1_amd64.deb
drwxr-xr-x root/root ...  ./
drwxr-xr-x root/root ...  ./usr/
drwxr-xr-x root/root ...  ./usr/bin/
-rwxr-xr-x root/root ...  ./usr/bin/hello
drwxr-xr-x root/root ...  ./usr/share/
drwxr-xr-x root/root ...  ./usr/share/doc/
drwxr-xr-x root/root ...  ./usr/share/doc/hello-c/
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c/changelog.Debian.gz
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c/README.Debian
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c/copyright
Caution
 Much more details need to be addressed before uploading the package to the Debian archive.

Debian Package

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.

Some people promote to package even programs which have been written especially for Debian in the non-native package format with the above workflow while generating the required tarball without debian/* files by oneself in advance. They claim that the use of non-native package format eases communication with the downstream distributions.

Packaging workflow

The Debian packaging workflow to create the Debian binary package involves generating several specifically named files (see [name-version]) as defined in the “Debian Policy Manual”.

The oversimplified method for the Debian packaging workflow can be summarized in 5 steps as follows.

  1. The upstream tarball is downloaded as the package-version.tar.gz file.

  2. The upstream tarball is untared 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/*:

      debian/rules

      The executable script for building the Debian package (see [rules])

      debian/control

      The package configuration file containing the source package name, the source build dependency, the binary package name, the binary dependency, etc. (see [control])

      debian/changelog

      The Debian package history file defining the upstream package version and the Debian revision in its first line (see [changelog])

      debian/copyright

      The copyright and license summary (see [copyright])

    • Optional specification files under the debian/* (see [debianconf]):

    • 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 "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), 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. (recommemded)

  7. Sign the package_version-revision.dsc and package_version-revision_arch.changes 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

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

Package name and version

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 ### are 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.

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

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:

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

debian/rules

The debian/rules script is the executable script to build the Debian package.

  • The debian/rules script re-targets the upstream build system (see [build]) 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 dh command is normally used as the front-end to the build system inside the debian/rules script.

  • $(DESTDIR) path depends on the build type.

    • $(DESTDIR)=debian/binarypackage (single binary package)

    • $(DESTDIR)=debian/tmp (multiple binary package)

dh

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.

  • dh clean : clean files in the source tree.

  • dh build : build the source tree

  • dh build-arch : build the source tree for architecture dependent packages

  • dh build-indep : build the source tree for architecture independent packages

  • dh install : install the binary files to $(DESTDIR)

  • dh install-arch : install the binary files to $(DESTDIR) for architecture dependent packages

  • dh install-indep : install the binary files to $(DESTDIR) for architecture independent packages

  • dh binary : generate the deb file

  • dh binary-arch : generate the deb file for architecture dependent packages

  • dh binary-indep : generate the deb file for architecture independent packages

Note
 The dh command exports compiler flags (CFLAGS, CXXFLAGS, FFLAGS, CPPFLAGS and LDFLAGS) with values as returned by dpkg-buildflags.

Simple debian/rules

Thanks to this abstraction of the dh command
[This simplicity is available since the version 7 of the debhelper package. This guide assumes the use of the debhelper version 9 or newer.]
, the Debian policy compliant debian/rules file supporting all the required targets can be written as simple as
[The debmake command generates a bit more complicated debian/rules file. But this is the core part.]
:

Simple debian/rules:
#!/usr/bin/make -f
#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)".
Tip
 Setting "DH_VERBOSE = 1" outputs every command that modifies files on the build system. Also it enables verbose build logs for some build systems.

Customized debian/rules

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 [build]) to address their irregularities using the package customization.

See [simple] 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 [harden]) and the multiarch customization (see [multiarch]).

Variables for debian/rules

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 the backport support etc..

vender.mk

DEB_VENDOR and DEB_PARENT_VENDOR variables; and dpkg_vendor_derives_from macro.
These are useful for the vendor support (Debian, Ubuntu, …).

architecture.mk

Set DEB_HOST_* and DEB_BUILD_* variables.
Only variables used explicitly in debian/rules need to be defined using dpkg-architecture. So there is no need to include this in debian/rules.

buildflags.mk

Set CFLAGS, CPPFLAGS, CXXFLAGS, OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS, FCFLAGS, and LDFLAGS buildflag variables.
These are normally exported by dh for the script in the override_** target. So there is no need to include this in debian/rules.

If you wish to use some of these useful variables in debian/rules, copy relevant codes to debian/rules or write simpler alternatives 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

See [multiarch], dpkg-architecture(1) and dpkg-buildflags(1).

debian/control

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:

  • meta data for the Debian source package

  • meta data for the Debian binary packages

The debmake command with the -b option (see [boption]) creates the initial template debian/control file with followings:

  • a set of Package stanzas defining the split of the Debian binary packages

  • a basic set of substvar used in each pertinent stanza

Split of the Debian binary package

For well behaving build systems, the split of the 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.

Please check examples in this guide:

  • [multipkg] (simple multi binary package example)

  • [librarypkg] (library related multi binary package example)

Substvar

The debian/control file also defines the package dependency in which the variable substitutions mechanism (substvar) may be used. See deb-substvars(5).

The debmake command supports 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

binNMU safe

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

    • Depends: foo (== ${binary:Version})

  • "Architecture: any" package depends on "Architecture: all" bar package

    • Depends: bar (== ${source:Version}

  • "Architecture: all" package depends on "Architecture: any" baz package

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

The library package name

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.

In order to distinguish the SONAME major version, their binary library pakages are named as libfoo7 and libfoo8 respectively.

You need to transition all dependent packages using binNMU by working with the release team.

In order to transition smoothly, the -dev package must follow one of the following naming rules:

  • Use the unversioned -dev package name: libfoo-dev

    • This is the normal rule.

    • Only one version of the library package is allowed in the archive.

    • This is good idea if the number of dependent packages are limited.

  • Use the versioned -dev package names: libfoo7-dev and libfoo8-dev

    • This is the special rule when you need to support both libfoo7 and libfoo8 simultaneously.

      • Make all dependent packages depend on libfoo-dev.

      • Make both libfoo7-dev and libfoo8-dev provide libfoo-dev.

      • The source package needs to be renamed as libfoo7-7.0.tar.gz and libfoo8-8.0.tar.gz respectively to make them both available in the archive.

      • The package specific install file path including libfoo7 and libfoo8 respectively for header files etc. needs to be chosen to make them co-installable.

    • This is useful if the number of dependent packages are huge and their migration poses major resource drain such as manual code updates, etc. Otherwise, please do not do this.

See Chapter 8 - Shared libraries of the “Debian Policy Manual”.

debmake -b

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.

  • Package:

  • Architecture:

  • Multi-Arch:

  • Depends:

  • Pre-Depends:

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

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

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

Here, binarypackage is the binary package name; and 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)

  • dbg: Debug symbol package (any, same) (alias: db)

  • 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, debmake warns you.

Here are some typical multiarch package split scenarios for the following upstream source examples:

  • a library source libfoo-1.0.tar.gz

  • a tool source bar-1.0.tar.gz written in a compiled language

  • a tool source baz-1.0.tar.gz written in an interpreted language

binarypackage type Architecture: Multi-Arch: Package content

libfoo1

lib*

any

same

the shared library, co-installable

libfoo1-dbg

dbg*

any

same

the shared library debug symbols, co-installable

libfoo-dev

dev*

any

same

the shared library header files etc., co-installable

libfoo-tools

bin*

any

foreign

the run-time support programs, not co-installable

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

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 [simple] 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
 If any dbg type packages are to be generated, they should be made for all bin and lib type packages.

debian/changelog

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 "LANG=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 set to sid.
[If you are using the vim editor, save with the ":wq" command.]

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

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.
[The licensecheck command from the devscripts package was referenced to make this internal checker.]

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.

DFSG

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.

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

  • Run the uscan command to download the new upstream tarball.

    • Alternatively, use the "gbp import-orig --uscan --pristine-tar" command.

  • The resulting tarball has the version number with an additional suffix +dfsg.

Other debian/*

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.

binarypackage.bug-control -x3

installed as usr/share/bug/binarypackage/control in binarypackage. See [bug].

binarypackage.bug-presubj -x3

installed as usr/share/bug/binarypackage/presubj in binarypackage. See [bug].

binarypackage.bug-script -x3

installed as usr/share/bug/binarypackage or usr/share/bug/binarypackage/script in binarypackage. See [bug].

clean -x2

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

compat -x1

Set the debhelper compatibility level (currently, "9").

See “COMPATIBILITY LEVELS” in debhelper(8).

binarypackage.conffile

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.

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

binarypackage.config

This is the debconf config script used for asking any questions necessary to configure the package. See [debconf].

binarypackage.cron.hourly -x3

Installed into the etc/cron/hourly/binarypackage file in binarypackage.

See dh_installcron(1) and cron(8).

binarypackage.cron.daily -x3

Installed into the etc/cron/daily/binarypackage file in binarypackage.

See dh_installcron(1) and cron(8).

binarypackage.cron.weekly -x3

Installed into the etc/cron/weekly/binarypackage file in binarypackage.

See dh_installcron(1) and cron(8).

binarypackage.cron.monthly -x3

Installed into the etc/cron/monthly/binarypackage file in binarypackage.

See dh_installcro*(1) and cron(8).

binarypackage.cron.d -x3

Installed into the etc/cron.d/binarypackage file in binarypackage.

See dh_installcron(1), cron(8), and crontab(5).

binarypackage.default -x3

If this exists, it is installed into etc/default/binarypackage in binarypackage.

See dh_installinit(1).

binarypackage.dirs -x3

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.

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

binarypackage.docs -x2

List documentation files to be installed in binarypackage.

See dh_installdocs(1).

binarypackage.emacsen-compat -x3

Installed into usr/lib/emacsen-common/packages/compat/binarypackage in binarypackage.

See dh_installemacsen(1).

binarypackage.emacsen-install -x3

Installed into usr/lib/emacsen-common/packages/install/binarypackage in binarypackage.

See dh_installemacsen(1).

binarypackage.emacsen-remove -x3

Installed into usr/lib/emacsen-common/packages/remove/binarypackage in binarypackage.

See dh_installemacsen(1).

binarypackage.emacsen-startup -x3

Installed into usr/lib/emacsen-common/packages/startup/binarypackage in binarypackage.

See dh_installemacsen(1).

binarypackage.examples -x2

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

See dh_installexamples(1).

gbp.conf

If this exists, it functions as the configuration file for the gbp command.

See gbp.conf(5), gbp(1), and git-buildpackage(1).

binarypackage.info -x2

List info files to be installed in binarypackage.

See dh_installinfo(1).

binarypackage.init -x3

Installed into etc/init.d/binarypackage in binarypackage.

See dh_installinit(1).

binarypackage.install -x2

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

license-examples/* -x4

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.

binarypackage.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 the whitespace.

See dh_link(1).

binarypackage.lintian-overrides -x3

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

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

binarypackage.manpages -x2

List man pages to be installed.

See dh_installman(1).

binarypackage.menu -x2

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.

See dh_installchangelogs(1).

patches/*

Collection of -p1 patch files which are applied to the upstream source before building the source.

See dpkg-source(8), [quilt] and [modpkg].

No patch files are generated by the debmake command.

patches/series -x1

The application sequence of the patches/* patch files.

binarypackage.preinst -x2
binarypackage.postinst -x2
binarypackage.prerm -x2
binarypackage.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 of the “Debian Policy Manual”.

See also debconf-devel(7) and 3.9.1 Prompting in maintainer scripts of 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.

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

See dh_systemd_enable(1), dh_systemd_start(1), and 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

    See “SOURCE PACKAGE FORMATS” in dpkg-source(8).

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.

See dh_lintian(1) and lintian(1).

source/local-options -x1

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

source/options

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

binarypackage.symbols -x2

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

See dh_makeshlibs(1) and [symbols]..

binarypackage.templates

This is the debconf templates file used for asking any questions necessary to configure the package. See [debconf].

tests/control

This is the RFC822-style test metadata file defined in DEP-8. See adt-run(1) and [ci].

TODO

Installed into the first binary package listed in the debian/control file as usr/share/doc/binarypackage/TODO.Debian.

See dh_installdocs(1).

binarypackage.tmpfile -x3

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

binarypackage.upstart -x3

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

See dh_installinit(1) and [emptypkg].

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 [signing-key]).

See [dfsg] and uscan(1).

Here are a few reminders to the above list.

  • For the single binary package, binarypackage. part of the filename in the list may be removed.

  • For the multi binary package, configuration file missing 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.

  • Configuration template filenames with -x1, -x2, -x3, or -x4 in the above mean that they are generated by the debmake command with that -x option (see [xoption]).

  • 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 the extra .ex suffix needs to be activated by removing that suffix.

  • Unused configuration template files generated by the debmake command should be removed.

  • Copy configuration template files as needed to the filenames matching their pertinent binary package names.

signing-key.pgp

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:

  • hello-version.tar.gz (upstream source)

  • hello-version.tar.gz.sig (detached signature)

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://keyserver.ubuntu.com:80 --recv-key 80EE4A00
gpg: requesting key 80EE4A00 from hkp server keyserver.ubuntu.com
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
 Here "hkp://keyserver.ubuntu.com:80" is used to avoid the firewall policy blocking HPK port 11371.

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.

Package customization

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:

  • patches/* approach

  • debian/rules approach

  • debian/bianrypackage.* approach

patches/* approach

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.

  • The diff command (manual)

  • The "git format-patches" command (manual for the git repository)

  • The dquilt command (manual, elegant) (alias of the quilt command, see [quilt])

  • The gbp-pq command (specialized, simple)

  • The git-dpm command (specialized, elegant)

  • Patches used in other distros and floating on the mailing list

  • …

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

These patches should apply cleanly. You must normalize them by the dquilt command (see [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 [modpkg] for example.

debian/rules approach

The customization to the Debian package build system can be done through the debian/rules file.

See [customrules].

debian/binarypackage.* approach

Add customized configuration files for the dh_* command from the debhelper package in the debian/ directory.

See [debianconf].

Upstream build systems

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

Autotools

Autotools (autoconf + automake) has 4 steps.

  1. setup the build system ("vim configure.ac Makefile.am" and "autoreconf -ivf")

  2. configure the build system ("./configure")

  3. build the source tree ("make")

  4. install the binary files ("make install")

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 step 2 to 4 at least. This is realized by the "dh $@ --with autotools-dev" command used in the debian/rules file.

The package maintainer wishes to take care step 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 and provides better porting supports.

Python distutils

Python distutils has 3 steps.

  1. setup and configure the build system ("vim setup.py")

  2. build the source tree ("python setup.py build")

  3. install the binary files ("python setup.py install")

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

Debugging information

The Debian package is build 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 can be packaged separately as the debug packege using the "dh_strip --dbg-package=package" command in the override_dh_strip: target of the debian/rules file.

The installation path of the debugging information is as follows to enable auto-loading of it by the gdb command.

  • /usr/lib/debug/.build-id/12/3456… (compat>=9, for buildID=123456…)

  • /usr/lib/debug/path/to/binary (compat<<9, for /path/to/binary)

See

Library package

Packaging the library software requires you to perform much more work than usual. Here are some reminders for packaging the library software:

  • Debian ships shared library such as /usr/lib/<triplet>/libfoo-0.1.so.1.0.0 (see [multiarch]).

  • Debian encourages to use versioned symbols in the shared library (see [symbols]).

  • Debian doesn’t ship *.la libtool library archive files.

  • Debian discourages to use and ship *.a static library files.

Before packaging the shared library software, see:

For the historic background study, see:

  • Escaping the Dependency Hell
    [This document was written before the introduction of the symbols file.]

    • This encourages to have versioned symbols in the shared library.

  • Debian Library Packaging guide
    [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 ftp-master (Steve Langasek). This document was written before the introduction of the multiarch system and the symbols file.]

Multiarch

The multiarch support for cross-architecture installation of binary packages (particularly i386 <-> 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.

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

The <triplet> value required by debhelper scripts is implicitly set in themselves.

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

The multiarch library path

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

  • If ./configure is used in the part of 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 on differences generated by the data byte order and by the compression algorithm.

Please note that --libexecdir 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 default is /usr/lib/. If such executable is "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.

Please also note that 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.

The multiarch header file path

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 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>/.
[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."]

The use of the file path containing packagename enables to have more than 2 development libraries simultaneously installed on a system.

The multiarch *.pc file path

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

Library symbols

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.

    • 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 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 new symbols:

      • You are done with the library packaging.

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

  • 8.6.3 The symbols system of the “Debian Policy Manual”

  • dh_makeshlibs(1)

  • dpkg-gensymbols(1)

  • dpkg-shlibdeps(1)

  • deb-symbols(5)

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.

Compiler hardening

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 [singlepkg] and dpkg-buildflags(1)).

Bug report

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

    • This file contains some directions such as redirecting the bug report to another package.

  • debian/binarypackage.bug-presubj → usr/share/bug/binarypackage/presubj

    • This file is displayed to the user by the reportbug command.

  • debian/binarypackage.bug-script → usr/share/bug/binarypackage or usr/share/bug/binarypackage/script

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

See dh_bugfiles(1) and reportbug’s Features for Developers

debconf

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

    • 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 of the “Debian Policy Manual”.

Continuous integration

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.

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

  • The jenkins package: generic CI platform

Tips

debdiff

You can compare file contents in two source Debian packages with the debdiff command.

$ debdiff old-package.dsc new-package.dsc

You can also compare file lists in two sets of binary Debian packages with the debdiff command.

$ debdiff old-package.changes new-package.changes

These are useful to identify what has been changed in the source packages and to check for inadvertent changes made when updating binary packages, such as unintentionally misplacing or removing files.

dget

You can download the set of files for the Debian source package with the dget command.

$ dget http://www.example.org/path/to/package_version-rev.dsc

debc

You should install generated packages with the debc command to test it locally.

$ debc package_version-rev_arch.changes

piuparts

You should install generated packages with the piuparts command to test it automatically.

$ sudo piuparts package_version-rev_arch.changes
Note
 This is very slow proess with the remote APT package repository access.

debsign

After completing the test of the package, you can sign it with the debsign command.

$ debsign package_version-rev_arch.changes

dput

After signing the package with the debsign command, you can upload the set of files for the Debian source and binary package with the dput command.

$ dput package_version-rev_arch.changes

bts

After uploading the package, you will recieve bug reports. It is an important duty of a package maintainer to manage these bugs properly as described in 5.8. Handling bugs of the “Debian Developer’s Reference”.

The bts command is a handy tool to manage bugs on Debian Bug Tracking System.

$ bts severity 123123 wishlist , tags -1 pending

git-buildpackage

The git-buildpackage package offers many commands to automate packaging activities using the git repository.

  • git-import-dsc: import the previous Debian source package to the git repository.

  • git-import-orig: import the new upstream tar to the git repository.

  • git-dch: generate the Debian changelog from the git commit messages.

  • git-buildpackage: build the Debian binary package from the git repository. (alias gbp)

    • The --pristine-tar option for the git-buildpackage command enables to store the upstream tarball in the same git repository.

    • The --uscan option for the git-buildpackage command enables to download and commit the new upstream tarball into the git repository.

  • git-pbuilder: build the Debian binary package from the git repository using the pbuilder package.

    • The cowbuilder package is used as its backend.

  • The gbp-pq, git-dpm or quilt (or alias dquilt) commands are used to manage quilt patches.

    • The use of the dquilt command is the simplest to learn and requires you to commit the resulting files manually with the git command to the master branch.

The package history management with the git-buildpackage package is becoming the standard practice for most Debian maintainers.

See:

Package history

For Debian source packages named <source-package> recorded in the snapshot.debian.org archive, an initial git repository with all of the Debian version history can be generated as follows.

$ git-import-dscs --debsnap --pristine-tar '<source-package>'

chroot

The chroot for the clean package build environment can be created and managed using the tools described in [setup].
[The git-pbuilder style organization is deployed here. See https://wiki.debian.org/git-pbuilder . Be careful since many HOWTOs use different organization.]

Here is a quick summary of available package build commands. There are many ways to do the same thing.

  • dpkg-buildpackage = core of package building tool

  • debuild = dpkg-buildpackage + lintian (build under the sanitized environment variables)

  • pbuilder = core of the Debian chroot environment tool

  • pdebuild = pbuilder + dpkg-buildpackage (build in the chroot)

  • cowbuilder = speed up the pbuilder execution

  • git-pbuilder = the easy-to-use commandline syntax for pdebuild (used by gbp buildpackge)

  • gbp = manage the Debian source under the git

  • gbp buildpackge = pbuilder + dpkg-buildpackage + gbp

A clean sid distribution chroot environment can be used as follows.

  • The chroot filesystem creation command for the sid distribution

    • pbuilder create

    • git-pbuilder create

  • The master chroot filesystem path for the sid distribution chroot

    • /var/cache/pbuilder/base.cow

  • The package build command for the sid distribution chroot

    • pdebuild

    • git-pbuilder

    • gbp buildpackage

  • The command to update the sid chroot

    • pbuilder --update

    • git-pbuilder --update

  • The command to login to the sid chroot to modify it

    • git-pbuilder --login --save-after-login

An arbitrary dist distribution environment can be used as follows.

  • The chroot filesystem creation command for the dist distribution

    • pbuilder create --distribution dist

    • DIST=dist git-pbuilder create

  • The master chroot filesystem path for the dist distribution chroot

    • path: /var/cache/pbuilder/base-dist.cow

  • The package build command for the dist distribution chroot

    • pdebuild -- --basepath=/var/cache/pbuilder/base-dist.cow

    • DIST=dist git-pbuilder

    • gbp buildpackage --git-dist=dist

  • The command to update the dist chroot

    • pbuilder update --basepath=/var/cache/pbuilder/base-dist.cow

    • DIST=dist git-pbuilder --update

  • The command to login to the sid chroot to modify it

    • pbuilder --login --basepath=/var/cache/pbuilder/base-dist.cow --save-after-login

    • DIST=dist git-pbuilder --login --save-after-login

Tip
 A custom environment with some pre-loaded packages needed for the new experimental packages, this git-pbuilder --login --save-after-login command is quite handy.
Tip
 If your old chroot is missing packages such as eatmydata, ccache, and lintian, you may want to install these with the git-pbuilder --login --save-after-login command.
Tip
 The chroot filesystem can be cloned simply by copying with "cp -a base-dist.cow base-customdist.cow". The new chroot can be accessed as "gbp buildpackage --git-dist=customdist" and "DIST=customdist git-pbuilder …".
Note
 The description in this section is too terse to be useful for most of the prospective maintainers. This is the intentional choice of the author. You are highly encouraged to search and read all the pertinent documents associated with the commands used.

New Debian revision

Let’s assume that a bug report #bug_number was filed against your package, and it describes a problem that you can solve by editing buggy file in the upstream source. Here’s what you need to do to create a new Debian revision of the package with the bugname.patch file recording the fix.

 $ dquilt new bugname.patch
 $ dquilt add buggy
 $ vim buggy
 $ dquilt refresh
 $ dquilt header -e
 $ while dquilt push; do dquilt refresh; done
 $ dquilt pop -a
 $ dch -i

Please make sure to describe concisely the changes that fix reported bugs and close those bugs by adding "Closes: #bug_number" in the debian/changlog file.

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.

New upstream release

If a package foo is properly packaged in the modern 3.0 (native) or 3.0 (quilt) formats, packaging a new upstream release is essentially moving the old debian/ directory to the new source. This can be done by running "tar -xvzf /path/to/foo_oldversion.debian.tar.gz" in the new extracted source.
[If a package foo is packaged in the old 1.0 format, this can be done by running "zcat /path/to/foo_oldversion.diff.gz|patch -p1" in the new extracted source, instead.]
 Of course, you need to do some obvious chores.

There are several tools to handle this situation. After updating to the new upstream release with these tools, please make sure to describe concisely the changes in the new upstream release that fix reported bugs and close those bugs by adding "Closes: #bug_number" in the debian/changlog file.

uupdate + tarball

You can update to the new upstream source with the uupdate command from the devscripts package. It requires to have the old Debian source package and the new upstream tarball.

 $ wget http://example.org/foo/foo-newversion.tar.gz
 $ cd foo-oldversion
 $ uupdate -v newversion ../foo-newversion.tar.gz
 ...
 $ cd ../foo-newversion
 $ while dquilt push; do dquilt refresh; done
 $ dch

uscan

You can update to the new upstream source with the uscan command from the devscripts package. It requires to have the old Debian source package and the debian/watch file in it.

 $ cd foo-oldversion
 $ uscan
 ...
 $ while dquilt push; do dquilt refresh; done
 $ dch

gbp

You can update to the new upstream source with the "gbp import-orig --pristine-tar" command from the git-buildpackage package. It requires to have the old Debian source in the git repository and the new upstream tarball.

 $ ln -sf foo-newversion.tar.gz foo_newversion.orig.tar.gz
 $ cd foo-vcs
 $ git checkout master
 $ gbp import-orig --pristine-tar  ../foo_newversion.orig.tar.gz
 ...
 $ while dquilt push; do dquilt refresh; done
 $ git commit -a -m "Refresh patches"
 $ dch

gbp + uscan

You can update to the new upstream source with the "gbp import-orig --pristine-tar --uscan" command from the git-buildpackage package. It requires to have the old Debian source in the git repository and the debian/watch file in it.

 $ cd foo-vcs
 $ git checkout master
 $ gbp import-orig --pristine-tar --uscan
 ...
 $ while dquilt push; do dquilt refresh; done
 $ git commit -a -m "Refresh patches"
 $ dch

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 [simple] can be done simply as follows.

 $ debmake -a package-1.0.tar.gz -i debuild
Tip
 URL such as "http://www.example.org/DL/package-1.0.tar.gz" may be used for the -a option.
Tip
 URL such as "http://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.

Upstream snapshot (-d, -t)

The upstream snapshot from the upstream source tree in 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 making of the non-native Debian packages 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 Debian non-native 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 Debian native binary package building case using the debuild command without the upstream tarball.

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

Python module

You can generate a functioning single binary Debian package with a reasonable package description directly from the Python module package offered as a tarball pythonmodule-1.0.tar.gz. The -b option specifying the package type python and the -s option to copy the package description from the upstream package need to be specified.

 $ debmake -s -b':python' -a pythonmodule-1.0.tar.gz -i debuild

For other interpreted languages with the -b option support, specify the pertinent type for the -b option.

For interpreted languages without the -b option support, specify the script type instead and add the interpreter package as the dependency of the resulting binary package by adjusting the debian/control file.

debmake -cc

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

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

With -c, this provides shorter report.

debmake -k

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

debmake -j

The generation of the functioning multi binary package always requires extra manual works than that of the functioning single binary package. The test build of the source package is essential part of it.

For example, let’s package the same package-1.0.tar.gz (see [simple]) into a multi binary package. At the line invoking the debmake command, let’s invoke it with the -j option instead for the test building and the report generation.

 $ debmake -j
Note
 The -j option for debmake 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 "debmake …" without -j and "debian/rules install" to check the install paths of the generated files.

  • Check the last lines of package.build-dep.log 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 the single binary package, too.)

  • Check the contents of package.install.log to identify the install paths for files to decide how you split them into multiple packages. 

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

 $ debuild

  • Each binarypackage_version-revision_arch.deb has files specified by the debian/binarypackage.install file.

Tip
 The binary package name starting with a "-" (hyphen) is treated as the abbreviated name and the real binary package name is generated by attaching it to the source package name.

debmake -x

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

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

3.0 source format

Updating the package style is not a required activity for the update of a package. However, doing so lets you use the full capabilities of the modern debhelper system and the 3.0 source format.

  • If you need to recreate deleted template files for any reason, you can run debmake again in the same Debian package source tree. Then edit them appropriately.

  • If the package has not been updated to use the dh command for the debian/rules file, update it to use it (see [simplerules]). Update the debian/control file accordingly.

  • If you have a 1.0 source package with the foo.diff.gz file, you can update it to the newer 3.0 (quilt) source format by creating debian/source/format with 3.0 (quilt). The rest of the debian/* files can just be copied. Import the big.diff file generated by the command "filterdiff -z -x /debian/ foo.diff.gz > big.diff" to your quilt system, if needed.
    [You can split big.diff into many small incremental patches using the splitdiff command.]

  • If it was packaged using another patch system such as dpatch, dbs, or cdbs with -p0, -p1, or -p2, convert it to the quilt command using the deb3 script in the quilt package.

  • If it was packaged with the dh command with the "--with quilt" option or with the dh_quilt_patch and dh_quilt_unpatch commands, remove these and make it use the newer 3.0 (quilt) source format.

  • If you have a 1.0 source package without the foo.diff.gz file, you can update it to the newer 3.0 (native) source format by creating debian/source/format with 3.0 (native). The rest of the debian/* files can just be copied.

You should check DEP - Debian Enhancement Proposals and adopt ACCEPTED proposals.

See ProjectsDebSrc3.0 to check the support status of the new Debian source formats by the Debian tool chains.

CDBS

The Common Debian Build System (CDBS) is a wrapper system over the debhelper package. The CDBS is based on the Makefile inclusion mechanism and configured by the DEB_* configuration variables set in the debian/rules file.

Before the introduction of the dh command to the debhelper package at the version 7, the CDBS was the only approach to create a simple and clean debian/rules file.

For many simple packages, the dh command alone allows us to make a simple and clean debian/rules file, now. It is desirable to keep the build system simple and clean by not using the superfluous CDBS.

Note
 “The CDBS magically does the job for me with less typing” nor “I don’t understand the new dh syntax” cannot be the excuse to keep using the CDBS system.

For some complicated packages such as GNOME related ones, the CDBS is used with reasons and offers some value to the packagers. If this is the case, please do not bother converting from the CDBS to the dh syntax.

Note
 If you are working with a team of maintainers, please follow the established practice of the team.

When converting packages from the CDBS to the dh syntax, please use the following as your reference:

UTF-8 conversion

If upstream documents are encoded in old encoding schemes, converting them to UTF-8 is a good idea.

Use the iconv command in the libc-bin package to convert encodings of plain text files.

iconv -f latin1 -t utf8 foo_in.txt > foo_out.txt

Use w3m(1) to convert from HTML files to UTF-8 plain text files. When you do this, make sure to execute it under UTF-8 locale.

LC_ALL=en_US.UTF-8 w3m -o display_charset=UTF-8 \
        -cols 70 -dump -no-graph -T text/html \
        < foo_in.html > foo_out.txt

Run these scripts in the override_dh_* target of the debian/rules file.

Source tips

Although the upstream tarball has all the information to build the Debian package, it is not always easy to figure out which combination of options to use.

Also, the upstream may be more focused on the feature enhancements and may be less eager for backward compatibilities etc. which are important aspect of the Debian packaging practice.

The leveraging of information from other distributions is an option to address above issues.

If the other distribution in interest is a Debian derivative one, it is trivial to reuse it.

If the other distribution in interest is a RPM based distribution, see Repackage src.rpm.

Downloading and opening of the src.rpm file can be done with the rget command. (Place the rget script in your PATH.)

rget script
#!/bin/sh
FCSRPM=$(basename $1)
mkdir ${FCSRPM}; cd ${FCSRPM}/
wget $1
rpm2cpio ${FCSRPM} | cpio -dium

Many upstream tarballs contain the SPEC file named as packagename.spec or packagename.spec.in used by the RPM system. This can be used as the baseline for the Debian package, too.

Packaging examples

There is an old Latin saying: “fabricando fit faber” (“practice makes perfect”).

It is highly recommended to practice and experiment with all the steps of Debian packaging with simple packages. This chapter provides you with the examples for your practice.

The /usr/share/doc/debmake/examples.tar.xz tarball has the sources used for testing the debmake command and creating the examples in this guide.

Cherry-pick templates

Although executing the debmake command with the larger -x[01234] option in the upstream source adds new template files without overwriting the existing ones, it tends to leave too many unused ones and is quite messy.

If you wish to get some template files without making mess in the upstream source tree, please consider the following scheme with an empty directory, e.g., package/.

 $ tree
.
└── package

1 directory, 0 files

Let’s get the maximum amount of template files by specifying the -x4 option.

Let’s also use the "-t -u 0.0" options to make missing upstream tarball with an upstream version 0.0.

 $ cd package
 $ debmake -t -u 0.0 -x4
 ...
I: debmake -x "4" ...
I: creating => debian/control
I: creating => debian/copyright
I: creating => debian/changelog
 ...
I: creating => debian/license-examples/LGPL-3.0+
I: creating => debian/license-examples/Artistic-1.0
I: creating => debian/license-examples/BSD-3-Clause
I: $ wrap-and-sort
I: upon return to the shell, current directory becomes /path/to/package
I: please execute "cd /path/to/package-0.0" before building the binary pack...
I: with dpkg-buildpackage (or debuild, pdebuild, sbuild, ...).

Let’s inspect generated template files.

 $ cd ..
 $ tree
.
├── package
├── package-0.0
│   └── debian
│       ├── changelog
│       ├── clean
│       ├── compat
│       ├── control
│       ├── copyright
│       ├── install
│       ├── license-examples
│       │   ├── Apache-2.0
│       │   ├── Artistic-1.0
│       │   ├── BSD-3-Clause
│       │   ├── GPL-2.0+
│       │   ├── GPL-3.0+
│       │   ├── LGPL-2.1+
│       │   ├── LGPL-3.0+
│       │   └── MIT
│       ├── links
│       ├── manpage.1.ex
│       ├── manpage.asciidoc.ex
│       ├── manpage.sgml.ex
│       ├── manpage.xml.ex
│       ├── menu
│       ├── package.bug-control.ex
│       ├── package.bug-presubj.ex
│       ├── package.bug-script.ex
│       ├── package.conffiles.ex
│       ├── package.cron.daily.ex
│       ├── package.cron.d.ex
│       ├── package.cron.hourly.ex
│       ├── package.cron.monthly.ex
│       ├── package.cron.weekly.ex
│       ├── package.default.ex
│       ├── package.dirs.ex
│       ├── package.emacsen-install.ex
│       ├── package.emacsen-remove.ex
│       ├── package.emacsen-startup.ex
│       ├── package.init.ex
│       ├── package.lintian-overrides.ex
│       ├── package.service.ex
│       ├── package.tmpfile.ex
│       ├── package.upstrat.ex
│       ├── patches
│       │   └── series
│       ├── postinst
│       ├── postrm
│       ├── preinst
│       ├── prerm
│       ├── README.Debian
│       ├── rules
│       ├── source
│       │   ├── format
│       │   └── local-options
│       ├── source.lintian-overrides.ex
│       └── watch
├── package_0.0.orig.tar.gz -> package-0.0.tar.gz
└── package-0.0.tar.gz

6 directories, 52 files

Now you can copy any of these generated template files in the package-0.0/debian/ directory to your package as needed.

Modifications

Let’s assume we have an older upstream source tarball hello-c-0.9.tar.gz than the hello-c-1.0.tar.gz in [simple]. The Makefile of version 0.9 installs its binary to the fixed location /usr/local/bin/hello and does not support $(DESTDIR).

There are several methods (see [patchapproach]) to prepare the -p1 patch needed for applying modifications to this 0.9 upstream source. Let’s use the dquilt command.

Patch file by the dquilt command

Here we show the method with the dquilt command.

The packaging procedure is the same as that of version 1.0 up to running the debmake command.

 $ cd hello-c-0.9
 $ debmake
D: /usr/bin/debmake started
D: PYTHONPATH = /usr/bin:/usr/lib/python3.4:/usr/lib/python3.4/plat-x86_64-...
I: set parameters
 ...
 ... (snip)
 ...
I: run "debmake -x2" to get more template files
I: $ wrap-and-sort

The "dquilt new …" command sets the name of the patch.

The "dquilt add …" command sets the files to be modified.

 $ dquilt new 0001-destdir.patch
Patch debian/patches/0001-destdir.patch is now on top
 $ dquilt add Makefile
File Makefile added to patch debian/patches/0001-destdir.patch
 $ cat Makefile
all: hello

hello: hello.c
        gcc -Wall -o hello hello.c

install: hello
        install -D hello /usr/local/bin/hello

clean:
        -rm -f hello

distclean: clean

.PHONY: all install clean distclean

The vim command edits the Makefile to support $(DESTDIR)..

The "dquilt refresh …" command records the modification as the -p1 patch in the debian/patches/ directory.

 $ vim Makefile
 ...
 $ cat Makefile
all: hello

hello: hello.c
        gcc -Wall -o hello hello.c

install: hello
        install -D hello $(DESTDIR)/usr/bin/hello

clean:
        -rm -f hello

distclean: clean

.PHONY: all install clean distclean
 $ dquilt refresh
Refreshed patch debian/patches/0001-destdir.patch
 $ cat debian/patches/0001-destdir.patch
Index: hello-c-0.9/Makefile
===================================================================
--- hello-c-0.9.orig/Makefile
+++ hello-c-0.9/Makefile
@@ -4,7 +4,7 @@ hello: hello.c
        gcc -Wall -o hello hello.c

 install: hello
-       install -D hello /usr/local/bin/hello
+       install -D hello $(DESTDIR)/usr/bin/hello

 clean:
        -rm -f hello

The "dquilt header -e …" command adds the DEP-3: Patch Tagging Guidelines compatible patch header.

The "dquilt pop -a" command removes all applied patches from the source.

 $ dquilt header -e
 ...
 $ cat debian/patches/0001-destdir.patch
From: Foo Bar <foo@example.org>
Description: make Makefile to support GNU coding standard
 $DESTDIR: debian/hello-c
 $prefix:  /usr/local -> /usr

Index: hello-c-0.9/Makefile
===================================================================
--- hello-c-0.9.orig/Makefile
+++ hello-c-0.9/Makefile
@@ -4,7 +4,7 @@ hello: hello.c
        gcc -Wall -o hello hello.c

 install: hello
-       install -D hello /usr/local/bin/hello
+       install -D hello $(DESTDIR)/usr/bin/hello

 clean:
        -rm -f hello
 $ dquilt pop -a
Removing patch debian/patches/0001-destdir.patch
Restoring Makefile

No patches applied
 $ cat debian/patches/series
### The patch files of the -p1 format included in the debian/patches direct...
### are applied to the upstream source in the order listed below.
### This is manually managed by users with dquilt (quilt(1) wrapper) etc.
### Also this may be updated by dpkg-source(1) when making a package.
0001-destdir.patch

For the proper packaging, you are required to make further modification here.

For learning purpose, let’s leave such details and move on. You can create a non-native Debian package using the debuild command (or its equivalents) in this source tree.

 $ cd hello-c-0.9
 $ debuild
 dpkg-buildpackage -rfakeroot -D -us -uc -i
 ...
dpkg-source: info: applying 0001-destdir.patch
 fakeroot debian/rules clean
dh clean
 ...
 debian/rules build
dh build
 ...
 fakeroot debian/rules binary
dh binary
 ...
Finished running lintian.

Let’s inspect files.

The generated files of version 0.9 by the debuild command:
 $ cd ..
 $ tree -L 1
.
├── hello-c-0.9
├── hello-c_0.9-1_amd64.build
├── hello-c_0.9-1_amd64.changes
├── hello-c_0.9-1_amd64.deb
├── hello-c_0.9-1.debian.tar.xz
├── hello-c_0.9-1.dsc
├── hello-c_0.9.orig.tar.gz -> hello-c-0.9.tar.gz
└── hello-c-0.9.tar.gz

1 directory, 7 files
The source package contents of version 0.9:
 $ dpkg -c hello-c_0.9-1_amd64.deb
drwxr-xr-x root/root ...  ./
drwxr-xr-x root/root ...  ./usr/
drwxr-xr-x root/root ...  ./usr/bin/
-rwxr-xr-x root/root ...  ./usr/bin/hello
drwxr-xr-x root/root ...  ./usr/share/
drwxr-xr-x root/root ...  ./usr/share/doc/
drwxr-xr-x root/root ...  ./usr/share/doc/hello-c/
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c/changelog.Debian.gz
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c/README.Debian
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c/copyright
The binary package contents of version 0.9:
 $ tar -tJf hello-c_0.9-1.debian.tar.xz
debian/
debian/patches/
debian/patches/0001-destdir.patch
debian/patches/series
debian/control
debian/changelog
debian/rules
debian/source/
debian/source/format
debian/README.Debian
debian/compat
debian/watch
debian/copyright
 $ tar -tzf hello-c-0.9.tar.gz
hello-c-0.9/
hello-c-0.9/Makefile
hello-c-0.9/hello.c

Snapshot (simple)

Let’s consider an upstream source in the VCS and make a snapshot package from it.

Let’s inspect files.

VCS source tree
 $ tree
.
└── hello-c
    ├── hello.c
    └── Makefile

1 directory, 2 files

The source is the same one as [singlepkg] but the parent directory lacks the version part. This is typical for the source in the VCS.

You create a non-native Debian package source tree from the above upstream example using the debmake(1) command.

git and debmake
 $ cd hello-c
 $ git init
Initialized empty Git repository in /path/to/hello-c/.git/
 $ git add .
 $ git commit -m "initial commit"
[master (root-commit) 9ac4c0a] initial commit
 2 files changed, 21 insertions(+)
 create mode 100644 Makefile
 create mode 100644 hello.c
 $ git checkout -b devel
Switched to a new branch 'devel'
 $ git branch
* devel
  master
 $ debmake -t
D: /usr/bin/debmake started
D: PYTHONPATH = /usr/bin:/usr/lib/python3.4:/usr/lib/python3.4/plat-x86_64-...
I: set parameters
I: sanity check of parameters
I: pkg="hello-c", ver="0~1410131356", rev="1"
I: make the upstream tarball with "tar --exclude=debian"
I: pwd = "/path/to/hello-c"
I: pwd = "/path/to"
I: $ rsync -aCv --link-dest=/path/to/hello-c hello-c/. hello-c-0~1410131356...
sending incremental file list
 ...
I: debmake -x "1" ...
 ...
I: run "debmake -x2" to get more template files
I: $ wrap-and-sort
I: upon return to the shell, current directory becomes /path/to/hello-c
I: please execute "cd /path/to/hello-c-0~1410131356" before building the bi...
I: with dpkg-buildpackage (or debuild, pdebuild, sbuild, ...).

Let’s inspect files.

 $ cd ..
 $ tree
.
├── hello-c
│   ├── hello.c
│   └── Makefile
├── hello-c-0~1410131356
│   ├── debian
│   │   ├── changelog
│   │   ├── compat
│   │   ├── control
│   │   ├── copyright
│   │   ├── patches
│   │   │   └── series
│   │   ├── README.Debian
│   │   ├── rules
│   │   ├── source
│   │   │   ├── format
│   │   │   └── local-options
│   │   └── watch
│   ├── hello.c
│   └── Makefile
├── hello-c_0~1410131356.orig.tar.gz -> hello-c-0~1410131356.tar.gz
└── hello-c-0~1410131356.tar.gz

5 directories, 16 files

There are many files:

  • the snapshot upstream tarball: hello-0~1410131356.tar.gz (hello-c_0~1410131356.orig.tar.gz)

  • the snapshot upstream source tree with template files generated by the debmake command: hello-c-0~1410131356/*

  • the cleaned VCS directory: hello-c-0~1410131356/*

For the proper packaging, you are required to make further modification using these auto-generated template files in the hello-c-0~1410131356/debian directory. For learning purpose, let’s leave such details and move on. You can create a non-native Debian package using the debuild command (or its equivalent) in this source tree.

 $ cd hello-c-0~1410131356
 $ debuild
 dpkg-buildpackage -rfakeroot -D -us -uc -i
 ...
 fakeroot debian/rules clean
dh clean
 ...
 debian/rules build
dh build
 ...
 fakeroot debian/rules binary
dh binary
 ...
Finished running lintian.

Let’s inspect the result.

 $ cd ..
 $ tree -L 1
.
├── hello-c
├── hello-c-0~1410131356
├── hello-c_0~1410131356-1_amd64.build
├── hello-c_0~1410131356-1_amd64.changes
├── hello-c_0~1410131356-1_amd64.deb
├── hello-c_0~1410131356-1.debian.tar.xz
├── hello-c_0~1410131356-1.dsc
├── hello-c_0~1410131356.orig.tar.gz -> hello-c-0~1410131356.tar.gz
└── hello-c-0~1410131356.tar.gz

2 directories, 7 files
 $ dpkg -c hello-c_0~1410131356-1_amd64.deb
drwxr-xr-x root/root ...  ./
drwxr-xr-x root/root ...  ./usr/
drwxr-xr-x root/root ...  ./usr/bin/
-rwxr-xr-x root/root ...  ./usr/bin/hello
drwxr-xr-x root/root ...  ./usr/share/
drwxr-xr-x root/root ...  ./usr/share/doc/
drwxr-xr-x root/root ...  ./usr/share/doc/hello-c/
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c/changelog.Debian.gz
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c/README.Debian
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c/copyright
 $ tar -tJf hello-c_0~1410131356-1.debian.tar.xz
debian/
debian/patches/
debian/patches/series
debian/control
debian/changelog
debian/rules
debian/source/
debian/source/format
debian/README.Debian
debian/compat
debian/watch
debian/copyright
 $ tar -tzf hello-c-0~1410131356.tar.gz
hello-c-0~1410131356/
hello-c-0~1410131356/Makefile
hello-c-0~1410131356/hello.c

Your development branch holding the working upstream source tree and the debian/* files is the devel branch.

The following will import generated Debian packages to master, upstream, and pristine-tar branches. (These are the 3 typical branches used by the gbp command.)

 $ cd hello-c
 $ git-import-dsc ../hello-c_0~1410131356-1.dsc  \
                  --pristine-tar --create-missing-branches
gbp:info: Tag upstream/0_1410131356 not found, importing Upstream tarball
gbp:info: Creating missing branch 'upstream'
pristine-tar: committed hello-c_0~1410131356.orig.tar.gz.delta to branch pr...
gbp:info: Version '0~1410131356-1' imported under 'hello-c'
 $ git branch
* devel
  master
  pristine-tar
  upstream
 $ gitk --all

The gitk command shows the VCS history nicely.

Snapshot (Autotools)

Let’s make this upstream source in the VCS more fun to use the Autotools (=Autoconf + Automake). The upstream VCS does not contain auto-generated files while the distributed tarball for the snapshot package has many auto-generated files.

Let’s inspect files.

VCS source tree
 $ tree
.
└── vcsdir
    ├── configure.ac
    ├── hello.c
    └── Makefile.am

1 directory, 3 files

Here are minimalistic configuration files for Autotools specifying the upstream version to be 1.5.

configure.ac:
 $ cat vcsdir/configure.ac
#                                               -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.
AC_PREREQ([2.69])
AC_INIT([hello-c], [1.5], [foo@example.org])
AC_CONFIG_SRCDIR([hello.c])
AC_CONFIG_HEADERS([config.h])
# Manually added
AM_INIT_AUTOMAKE([foreign])
# Checks for programs.
AC_PROG_CC
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
Makefile.am:
 $ cat vcsdir/Makefile.am
bin_PROGRAMS = hello
hello_SOURCES = hello.c

The C source hello.c is the same one as before.

You create a non-native Debian package source tree from the above upstream example using the debmake(1) command.

git and debmake
 $ cd vcsdir
 $ git init
Initialized empty Git repository in /path/to/vcsdir/.git/
 $ git add .
 $ git commit -m "initial commit"
[master (root-commit) ef54390] initial commit
 3 files changed, 21 insertions(+)
 create mode 100644 Makefile.am
 create mode 100644 configure.ac
 create mode 100644 hello.c
 $ git checkout -b devel
Switched to a new branch 'devel'
 $ git branch
* devel
  master
 $ debmake -d
D: /usr/bin/debmake started
D: PYTHONPATH = /usr/bin:/usr/lib/python3.4:/usr/lib/python3.4/plat-x86_64-...
I: set parameters
I: sanity check of parameters
I: pkg="", ver="", rev="1"
I: make the upstream tarball with "make dist" equivalents
I: pwd = "/path/to/vcsdir"
I: $ autoreconf -ivf && ./configure --prefix "/usr" && make distcheck
autoreconf: Entering directory `.'
 ...
I: debmake -x "1" ...
 ...
I: run "debmake -x2" to get more template files
I: $ wrap-and-sort
I: upon return to the shell, current directory becomes /path/to/vcsdir
I: please execute "cd /path/to/hello-c-1.5" before building the binary pack...
I: with dpkg-buildpackage (or debuild, pdebuild, sbuild, ...).

Let’s clean vcsdir/ since it has so many Autotools generated files.

 $ git clean -d -f -x
Removing .deps/
Removing Makefile
Removing Makefile.in
Removing aclocal.m4
Removing autom4te.cache/
Removing compile
Removing config.h
Removing config.h.in
Removing config.log
Removing config.status
Removing configure
Removing depcomp
Removing hello-c-1.5.tar.gz
Removing install-sh
Removing missing
Removing stamp-h1

Let’s inspect files.

 $ cd ..
 $ tree
.
├── hello-c-1.5
│   ├── aclocal.m4
│   ├── compile
│   ├── config.h.in
│   ├── configure
│   ├── configure.ac
│   ├── debian
│   │   ├── changelog
│   │   ├── compat
│   │   ├── control
│   │   ├── copyright
│   │   ├── patches
│   │   │   └── series
│   │   ├── README.Debian
│   │   ├── rules
│   │   ├── source
│   │   │   ├── format
│   │   │   └── local-options
│   │   └── watch
│   ├── depcomp
│   ├── hello.c
│   ├── install-sh
│   ├── Makefile.am
│   ├── Makefile.in
│   └── missing
├── hello-c_1.5.orig.tar.gz -> hello-c-1.5.tar.gz
├── hello-c-1.5.tar.gz
└── vcsdir
    ├── configure.ac
    ├── hello.c
    └── Makefile.am

5 directories, 26 files

There are many files:

  • the snapshot upstream tarball: hello-1.5.tar.gz (hello-c_1.5.orig.tar.gz)

  • the snapshot upstream source tree with template files generated by the debmake command: hello-c-1.5/*

  • the cleaned VCS directory: vcsdir/*

For the proper packaging, you are required to make further modification using these auto-generated template files in the hello-c-1.5/debian directory. For learning purpose, let’s leave such details and move on. You can create a non-native Debian package using the debuild command (or its equivalent) in this source tree.

 $ cd hello-c-1.5
 $ debuild
 dpkg-buildpackage -rfakeroot -D -us -uc -i
 ...
 fakeroot debian/rules clean
dh clean --with autoreconf
 ...
 debian/rules build
dh build --with autoreconf
 ...
 fakeroot debian/rules binary
dh binary --with autoreconf
 ...
Finished running lintian.

Let’s inspect the result.

 $ cd ..
 $ tree -L 1
.
├── hello-c-1.5
├── hello-c_1.5-1_amd64.build
├── hello-c_1.5-1_amd64.changes
├── hello-c_1.5-1_amd64.deb
├── hello-c_1.5-1.debian.tar.xz
├── hello-c_1.5-1.dsc
├── hello-c_1.5.orig.tar.gz -> hello-c-1.5.tar.gz
├── hello-c-1.5.tar.gz
└── vcsdir

2 directories, 7 files
 $ dpkg -c hello-c_1.5-1_amd64.deb
drwxr-xr-x root/root ...  ./
drwxr-xr-x root/root ...  ./usr/
drwxr-xr-x root/root ...  ./usr/bin/
-rwxr-xr-x root/root ...  ./usr/bin/hello
drwxr-xr-x root/root ...  ./usr/share/
drwxr-xr-x root/root ...  ./usr/share/doc/
drwxr-xr-x root/root ...  ./usr/share/doc/hello-c/
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c/changelog.Debian.gz
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c/README.Debian
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c/copyright
 $ tar -tJf hello-c_1.5-1.debian.tar.xz
debian/
debian/patches/
debian/patches/series
debian/control
debian/changelog
debian/rules
debian/source/
debian/source/format
debian/README.Debian
debian/compat
debian/watch
debian/copyright
 $ tar -tzf hello-c-1.5.tar.gz
hello-c-1.5/
hello-c-1.5/config.h.in
hello-c-1.5/Makefile.am
hello-c-1.5/Makefile.in
hello-c-1.5/hello.c
hello-c-1.5/configure
hello-c-1.5/depcomp
hello-c-1.5/missing
hello-c-1.5/configure.ac
hello-c-1.5/install-sh
hello-c-1.5/compile
hello-c-1.5/aclocal.m4

Your development branch holding the real upstream source tree is the devel branch.

The following will import generated Debian packages to master, upstream, and pristine-tar branches.

 $ cd vcsdir
 $ git-import-dsc ../hello-c_1.5-1.dsc  \
                  --pristine-tar --create-missing-branches
gbp:info: Tag upstream/1.5 not found, importing Upstream tarball
gbp:info: Creating missing branch 'upstream'
pristine-tar: committed hello-c_1.5.orig.tar.gz.delta to branch pristine-ta...
gbp:info: Version '1.5-1' imported under 'hello-c'
 $ git branch
* devel
  master
  pristine-tar
  upstream
 $ gitk --all

The gitk command shows the VCS history nicely.

Snapshot (Python)

Let’s consider another upstream source in the VCS and make a snapshot package from it. Let’s assume this is a Python3 source package with the distutils.

Let’s inspect files.

 $ tree
.
└── vcsdir
    ├── hello-py
    │   └── __init__.py
    ├── MANIFEST
    ├── MANIFEST.in
    ├── PKG-INFO
    ├── scripts
    │   └── hello
    └── setup.py

3 directories, 6 files

Here are minimalistic configuration files for distutils with the upstream version 1.0..

setup.py:
 $ cat vcsdir/setup.py
#!/usr/bin/python3
# vi:se ts=4 sts=4 et ai:
from distutils.core import setup

setup(name='hello-py',
    version='1.0',
    description='Hello Python',
    long_description='Hello Python program.',
    author='Osamu Aoki',
    author_email='osamu@debian.org',
    url='http://people.debian.org/~osamu/',
    packages=['hello-py'],
    package_dir={'hello-py': 'hello-py'},
    scripts=['scripts/hello'],
    classifiers = ['Development Status :: 3 - Alpha',
        'Environment :: Console',
        'Intended Audience :: Developers',
        'License :: OSI Approved :: MIT License',
        'Natural Language :: English',
        'Operating System :: POSIX :: Linux',
        'Programming Language :: Python :: 3',
        'Topic :: Utilities',
    ],
    platforms   = 'POSIX',
    license     = 'MIT License'
)

The Python program code is as follows.

scripts/hello and hello-py/init.py
 $ cat vcsdir/scripts/hello
#!/usr/bin/python3
# vim:se tw=0 sts=4 ts=4 et si:
"""
Copyright © 2014 Osamu Aoki
 ...
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
"""

import hello-py

if __name__ == '__main__':
    hello.main()

 $ cat vcsdir/hello-py/__init__.py
#!/usr/bin/python3
# vim:se tw=0 sts=4 ts=4 et ai:

def main():
    print('Hello Python3!')
    return

if __name__ == '__main__':
    main()

You create a non-native Debian package source tree from the above upstream example using the debmake(1) command. Here package description is copied from the upstream setup.py content by the -s option.

 $ cd vcsdir
 $ git init
Initialized empty Git repository in /path/to/vcsdir/.git/
 $ git add .
 $ git commit -m "initial commit"
[master (root-commit) 24f4e27] initial commit
 6 files changed, 93 insertions(+)
 create mode 100644 MANIFEST
 create mode 100644 MANIFEST.in
 create mode 100644 PKG-INFO
 create mode 100755 hello-py/__init__.py
 create mode 100755 scripts/hello
 create mode 100755 setup.py
 $ git branch devel
 $ git branch upstream
 $ git branch
  devel
* master
  upstream
 $ debmake -s -b':python3' -d -i debuild
 ...
I: debmake -x "1" ...
 ...
Finished running lintian.
I: upon return to the shell, current directory becomes /path/to/vcsdir
I: please execute "cd .." and inspect the build results.
 $ git clean -d -f
Removing dist/

Let’s inspect the result.

 $ cd ..
 $ tree -L 1
.
├── hello-py-1.0
├── hello-py_1.0-1_all.deb
├── hello-py_1.0-1_amd64.build
├── hello-py_1.0-1_amd64.changes
├── hello-py_1.0-1.debian.tar.xz
├── hello-py_1.0-1.dsc
├── hello-py_1.0.orig.tar.gz -> hello-py-1.0.tar.gz
├── hello-py-1.0.tar.gz
└── vcsdir

2 directories, 7 files
 $ dpkg -c hello-py_1.0-1_all.deb
drwxr-xr-x root/root ...  ./
drwxr-xr-x root/root ...  ./usr/
drwxr-xr-x root/root ...  ./usr/bin/
-rwxr-xr-x root/root ...  ./usr/bin/hello
drwxr-xr-x root/root ...  ./usr/lib/
drwxr-xr-x root/root ...  ./usr/lib/python3/
drwxr-xr-x root/root ...  ./usr/lib/python3/dist-packages/
-rw-r--r-- root/root ...  ./usr/lib/python3/dist-packages/hello_py-1.0.egg-...
drwxr-xr-x root/root ...  ./usr/lib/python3/dist-packages/hello-py/
-rw-r--r-- root/root ...  ./usr/lib/python3/dist-packages/hello-py/__init__...
drwxr-xr-x root/root ...  ./usr/share/
drwxr-xr-x root/root ...  ./usr/share/doc/
drwxr-xr-x root/root ...  ./usr/share/doc/hello-py/
-rw-r--r-- root/root ...  ./usr/share/doc/hello-py/changelog.Debian.gz
-rw-r--r-- root/root ...  ./usr/share/doc/hello-py/README.Debian
-rw-r--r-- root/root ...  ./usr/share/doc/hello-py/copyright
 $ tar -tJf hello-py_1.0-1.debian.tar.xz
debian/
debian/patches/
debian/patches/series
debian/control
debian/changelog
debian/rules
debian/source/
debian/source/format
debian/README.Debian
debian/compat
debian/watch
debian/copyright
 $ tar -tzf hello-py-1.0.tar.gz
hello-py-1.0/
hello-py-1.0/MANIFEST.in
hello-py-1.0/MANIFEST
hello-py-1.0/PKG-INFO
hello-py-1.0/hello-py/
hello-py-1.0/hello-py/__init__.py
hello-py-1.0/setup.py
hello-py-1.0/scripts/
hello-py-1.0/scripts/hello

Let’s check the generated control file content.

 $ dpkg -e hello-py_1.0-1_all.deb
 $ tree DEBIAN
DEBIAN
├── control
├── md5sums
├── postinst
└── prerm

0 directories, 4 files

Let’s compare how the packaging process converts the substvar etc.

debian/control in the source package
 $ cat hello-py-1.0/debian/control
Source: hello-py
Section: unknown
Priority: extra
Maintainer: "Firstname Lastname" <email.address@example.org>
Build-Depends: debhelper (>=9), dh-python, python3-all
Standards-Version: 3.9.5
Homepage: <insert the upstream URL, if relevant>
X-Python3-Version: >= 3.2

Package: hello-py
Architecture: all
Multi-Arch: foreign
Depends: ${misc:Depends}, ${python3:Depends}
Description: Hello Python
 Hello Python program.
DEBIAN/control in the binary package
 $ cat DEBIAN/control
Package: hello-py
Version: 1.0-1
Architecture: all
Maintainer: "Firstname Lastname" <email.address@example.org>
Installed-Size: 50
Depends: python3:any (>= 3.3.2-2~), python3
Section: unknown
Priority: extra
Multi-Arch: foreign
Homepage: <insert the upstream URL, if relevant>
Description: Hello Python
 Hello Python program.

Multi binary package

Let’s consider an upstream package hello-1.1.tar.gz and untar it to inspect files.

 $ tree
.
├── hello-1.1
│   ├── hello.c
│   ├── hello.data
│   ├── hello-sh
│   └── Makefile
└── hello-1.1.tar.gz

1 directory, 5 files

This is similar to the previously shown hello-c-1.0.tar.gz but with a few additional files and changes.

The C source hello.c is the same one.

Makefile is updated to support $(DESTDIR) for all files.

 $ cat hello-1.1/Makefile
all: hello

hello: hello.c
        gcc -Wall -o hello hello.c

install: hello hello.data
        install -D hello $(DESTDIR)/usr/bin/hello
        install -D hello-sh $(DESTDIR)/usr/bin/hello-sh
        install -D hello.data $(DESTDIR)/usr/share/hello/hello.data

clean:
        -rm -f hello

distclean: clean

.PHONY: all install clean distclean

There is an additional simple shell script hello-sh.

 $ cat hello-1.1/hello-sh
#!/bin/sh
echo "Hello from the shell!"

The hello.data file is a dummy data for this training.

Let’s create a set of the following non-native binary Debian packages.

  • hello-c : type=bin, This package contains an ELF executable hello file compiled from the source file hello.c.

  • hello-c-dbg : type=dbg, This package contains debug symbols data of the ELF executable file hello.

  • hello-sh : type=script, This contains the shell script hello-sh.

  • hello-data : type=data, This contains the data file hello.data.

Since we are splitting the generated files into multiple packages, we package this in two steps. The first step is the "debmake -j …" command (see [testbuild]).

The debmake execution (1st stage)
 $ cd hello-1.1
 $ debmake -j -b'-c,-c-dbg,-data:data,-sh:script'
 ...
 ... (snip)
 ...
I: $ LANG=C ; sed -e "1d" < ../hello.depcheck.log | sort >../hello.build-de...
I: $ LANG=C; find debian/tmp -type f 2>&1 | sed -e "s/^debian\/tmp\///" | s...
I: upon return to the shell, current directory becomes /path/to/hello-1.1
I: please execute "cd /path/to/hello-1.1" before building the binary packag...
I: with dpkg-buildpackage (or debuild, pdebuild, sbuild, ...).
The parent directory after the "debmake -j …" execution.
 $ cd ..
 $ tree -L 1
.
├── hello-1.1
├── hello_1.1.orig.tar.gz -> hello-1.1.tar.gz
├── hello-1.1.tar.gz
├── hello.build-dep.log
├── hello.build.log
├── hello.depcheck.log
└── hello.install.log

1 directory, 6 files

There are 2 log files in the parent directory.

hello.build-dep.log generated by the dpkg-depcheck command
 $ cat hello.build-dep.log
  debhelper
  libfakeroot:amd64
  liblocale-gettext-perl
  make-guile
  perl-modules

The build dependency to the debhelper package is always implemented by the debmake command.

The dependency to other packages (libfakeroot:amd64, liblocale-gettext-perl, perl-modules) seems to be false positives caused by the build tools used such as the pdebuild command.

For this packaging case, there is no additional package required be listed as the build dependency.

hello.install.log listing files under the debian/tmp directory
 $ cat hello.install.log
usr/bin/hello
usr/bin/hello-sh
usr/share/hello/hello.data

Now we know what files are generated in the debian/tmp directory.

Let’s start with the fresh source tree and build package from there. Let’s skip generating tutorial comment lines by using the -Q option.

The debmake execution (2nd stage)
 $ rm -rf hello-1.1
 $ debmake -Q -b'-c,-c-dbg,-data:data,-sh:script' -a hello-1.1.tar.gz
D: /usr/bin/debmake started
D: PYTHONPATH = /usr/bin:/usr/lib/python3.4:/usr/lib/python3.4/plat-x86_64-...
I: set parameters
 ...
I: parse binary package settings: -c,-c-dbg,-data:data,-sh:script
I: binary package=hello-c Type=bin / Arch=any M-A=foreign
I: binary package=hello-c-dbg Type=dbg / Arch=any M-A=same
I: binary package=hello-data Type=data / Arch=all M-A=foreign
I: binary package=hello-sh Type=script / Arch=all M-A=foreign
 ...
I: debmake -x "2" ...
 ...
I: $ wrap-and-sort
I: upon return to the shell, current directory becomes /path/to
I: please execute "cd /path/to/hello-1.1" before building the binary packag...
I: with dpkg-buildpackage (or debuild, pdebuild, sbuild, ...).

Please note that the debmake command is run with the -x2 option as the default for the new multi binary packages.

 $ cd hello-1.1
 $ tree
.
├── debian
│   ├── changelog
│   ├── clean
│   ├── compat
│   ├── control
│   ├── copyright
│   ├── hello-c.doc-base
│   ├── hello-c.docs
│   ├── hello-c.examples
│   ├── hello-c.info
│   ├── hello-c.install
│   ├── hello-c.links
│   ├── hello-c.manpages
│   ├── hello-c.menu
│   ├── hello-c.postinst
│   ├── hello-c.postrm
│   ├── hello-c.preinst
│   ├── hello-c.prerm
│   ├── hello-data.install
│   ├── hello-sh.install
│   ├── patches
│   │   └── series
│   ├── README.Debian
│   ├── rules
│   ├── source
│   │   ├── format
│   │   └── local-options
│   └── watch
├── hello.c
├── hello.data
├── hello-sh
└── Makefile

3 directories, 29 files

Let’s inspect generated template files.

debian/rules:
 $ cat debian/rules
#!/usr/bin/make -f
#DH_VERBOSE = 1
#export DEB_BUILD_MAINT_OPTIONS = hardening=+all
#export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
#export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

%:
        dh $@

override_dh_strip:
        dh_strip --dbg-package=hello-c-dbg

This is essentially the standard debian/rules file with the dh command with override_dh_strip to create a debug package. (There are some commented out contents for you to customize it.)

debian/control:
 $ cat debian/control
Source: hello
Section: unknown
Priority: extra
Maintainer: "Firstname Lastname" <email.address@example.org>
Build-Depends: debhelper (>=9)
Standards-Version: 3.9.5
Homepage: <insert the upstream URL, if relevant>

Package: hello-c
Architecture: any
Multi-Arch: foreign
Depends: ${misc:Depends}, ${shlibs:Depends}
Description: auto-generated package by debmake: bin
 This package contains the compiled binary executable.
 ...
 ... (snip)
 ...

Package: hello-c-dbg
Section: debug
Architecture: any
Multi-Arch: same
Depends: hello-c (= ${binary:Version}), ${misc:Depends}
Description: auto-generated package by debmake: dbg
 This package contains the debugging symbols.

Package: hello-data
Architecture: all
Multi-Arch: foreign
Depends: ${misc:Depends}
Description: auto-generated package by debmake: data
 This package contains the architecture independent data.

Package: hello-sh
Architecture: all
Multi-Arch: foreign
Depends: ${misc:Depends}
Description: auto-generated package by debmake: script
 This package contains the script program.

It is nice to see that the template files are generated with reasonable contents.

There are several template files under the debian/ directory. Let’s customize them and erase unnecessary ones. (Here, we are skipping details required by the best practice.)

Manual adjustments of debian/*
 $ cd ./debian
 $ rm -f *.do* *.examples *.info *.links *.m*  *.p*
 $ rm hello-c-dbg.install
rm: cannot remove ‘hello-c-dbg.install’: No such file or directory
 $ echo usr/bin/hello > hello-c.install
 $ echo usr/share/hello/hello.data > hello-data.install
 $ echo usr/bin/hello-sh > hello-sh.install

You can create a non-native Debian package using the debuild command (or its equivalents) in this source tree.

 $ cd ..
 $ debuild
 dpkg-buildpackage -rfakeroot -D -us -uc -i
 ...
dpkg-buildpackage: host architecture amd64
 fakeroot debian/rules clean
dh clean
 ...
 debian/rules build
dh build
 ...
 fakeroot debian/rules binary
dh binary
 ...
Finished running lintian.

Let’s inspect the result.

The generated files of version 1.0 by the debuild command:
 $ cd ..
 $ tree -L 1
.
├── hello-1.1
├── hello_1.1-1_amd64.build
├── hello_1.1-1_amd64.changes
├── hello_1.1-1.debian.tar.xz
├── hello_1.1-1.dsc
├── hello_1.1.orig.tar.gz -> hello-1.1.tar.gz
├── hello-1.1.tar.gz
├── hello.build-dep.log
├── hello.build.log
├── hello-c_1.1-1_amd64.deb
├── hello-c-dbg_1.1-1_amd64.deb
├── hello-data_1.1-1_all.deb
├── hello.depcheck.log
├── hello.install.log
└── hello-sh_1.1-1_all.deb

1 directory, 14 files
The source package contents of version 1.0:
 $ tar -tJf hello_1.1-1.debian.tar.xz
debian/
debian/patches/
debian/patches/series
debian/control
debian/hello-sh.install
debian/changelog
debian/clean
debian/rules
debian/source/
debian/source/format
debian/README.Debian
debian/compat
debian/hello-data.install
debian/watch
debian/hello-c.install
debian/copyright
 $ tar -tzf hello-1.1.tar.gz
hello-1.1/
hello-1.1/hello-sh
hello-1.1/Makefile
hello-1.1/hello.c
hello-1.1/hello.data
The binary package contents of version 1.0:
 $ dpkg -c hello-c_1.1-1_amd64.deb
drwxr-xr-x root/root ...  ./
drwxr-xr-x root/root ...  ./usr/
drwxr-xr-x root/root ...  ./usr/bin/
-rwxr-xr-x root/root ...  ./usr/bin/hello
drwxr-xr-x root/root ...  ./usr/share/
drwxr-xr-x root/root ...  ./usr/share/doc/
drwxr-xr-x root/root ...  ./usr/share/doc/hello-c/
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c/changelog.Debian.gz
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c/README.Debian
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c/copyright
 $ dpkg -c hello-c-dbg_1.1-1_amd64.deb
drwxr-xr-x root/root ...  ./
drwxr-xr-x root/root ...  ./usr/
drwxr-xr-x root/root ...  ./usr/lib/
drwxr-xr-x root/root ...  ./usr/lib/debug/
drwxr-xr-x root/root ...  ./usr/lib/debug/.build-id/
drwxr-xr-x root/root ...  ./usr/lib/debug/.build-id/e5/
-rw-r--r-- root/root ...  ./usr/lib/debug/.build-id/e5/0948fb440ec9f6ffcf37...
drwxr-xr-x root/root ...  ./usr/share/
drwxr-xr-x root/root ...  ./usr/share/doc/
drwxr-xr-x root/root ...  ./usr/share/doc/hello-c-dbg/
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c-dbg/changelog.Debian.gz
-rw-r--r-- root/root ...  ./usr/share/doc/hello-c-dbg/copyright
 $ dpkg -c hello-data_1.1-1_all.deb
drwxr-xr-x root/root ...  ./
drwxr-xr-x root/root ...  ./usr/
drwxr-xr-x root/root ...  ./usr/share/
drwxr-xr-x root/root ...  ./usr/share/hello/
-rwxr-xr-x root/root ...  ./usr/share/hello/hello.data
drwxr-xr-x root/root ...  ./usr/share/doc/
drwxr-xr-x root/root ...  ./usr/share/doc/hello-data/
-rw-r--r-- root/root ...  ./usr/share/doc/hello-data/changelog.Debian.gz
-rw-r--r-- root/root ...  ./usr/share/doc/hello-data/copyright
 $ dpkg -c hello-sh_1.1-1_all.deb
drwxr-xr-x root/root ...  ./
drwxr-xr-x root/root ...  ./usr/
drwxr-xr-x root/root ...  ./usr/bin/
-rwxr-xr-x root/root ...  ./usr/bin/hello-sh
drwxr-xr-x root/root ...  ./usr/share/
drwxr-xr-x root/root ...  ./usr/share/doc/
drwxr-xr-x root/root ...  ./usr/share/doc/hello-sh/
-rw-r--r-- root/root ...  ./usr/share/doc/hello-sh/changelog.Debian.gz
-rw-r--r-- root/root ...  ./usr/share/doc/hello-sh/copyright
Note
 For the normal multi binary package case, you must provide binarypackage.install files for all binary packages (excluding dbg type ones). The build result is split into the binary packages by moving files from the debian/tmp/ directory to the directories named after the binary packages.

Library package

Let’s consider an upstream package libkkc-0.3.2.tar.gz.

Step 0: Untar …
 $ tar -xzmf libkkc-0.3.2.tar.gz
 $ cd libkkc-0.3.2
 $ git init
Initialized empty Git repository in /path/to/libkkc-0.3.2/.git/
 $ git add .
 $ git commit -m 'initial import of libkkc-0.3.2.tar.gz'
[master (root-commit) dd36e4b] initial import of libkkc-0.3.2.tar.gz
 423 files changed, 211360 insertions(+)
 ...
 ... (snip)
 ...
 create mode 100644 tools/kkc.vala
 create mode 100644 tools/kkc_vala.stamp
 $ git branch upstream
 $ git tag upstream/0.3.2
 $ pristine-tar commit ../libkkc-0.3.2.tar.gz
pristine-tar: committed libkkc-0.3.2.tar.gz.delta to branch pristine-tar

Let’s make a test build this with the -j option (see [testbuild]).

Step 1: debmake -j
 $ debmake -j
D: /usr/bin/debmake started
D: PYTHONPATH = /usr/bin:/usr/lib/python3.4:/usr/lib/python3.4/plat-x86_64-...
I: set parameters
I: sanity check of parameters
I: pkg="libkkc", ver="0.3.2", rev="1"
I: *** start packaging in "libkkc-0.3.2". ***
I: provide libkkc_0.3.2.orig.tar.gz for non-native Debian package
 ...
 ... (snip)
 ...
I: $ wrap-and-sort
I: $ fakeroot dpkg-depcheck -m -C -o ../libkkc.depcheck.log -f -catch-alter...
I: $ LANG=C ; sed -e "1d" < ../libkkc.depcheck.log | sort >../libkkc.build-...
I: $ LANG=C; find debian/libkkc -type f 2>&1 | sed -e "s/^debian\/libkkc\//...
I: upon return to the shell, current directory becomes /path/to/libkkc-0.3....
I: please execute "cd /path/to/libkkc-0.3.2" before building the binary pac...
I: with dpkg-buildpackage (or debuild, pdebuild, sbuild, ...).

Let’s inspect the package dependency.

libkkc.build-dep.log
 $ cat ../libkkc.build-dep.log
  bison
  cmake-data
  cpio
  dh-autoreconf
  gawk
  gobject-introspection
  gtk-doc-tools
  gvfs:amd64
  libc6-i386
  libc6-x32
  libexpat1-dev:amd64
  libfakechroot:amd64
  libfakeroot:amd64
  libfreetype6-dev
  libgee-dev
  libgirepository-1.0-1
  libgirepository1.0-dev
  libglib2.0-dev
  libgpg-error-dev
  libgtk-3-dev
  libgtk2.0-dev
  libjson-glib-dev
  liblocale-gettext-perl
  libltdl-dev:amd64
  libmarisa-dev:amd64
  libnspr4-dev
  libpython2.7-stdlib:amd64
  libselinux1:i386
  libwayland-dev
  libxml2-dev:amd64
  mime-support
  perl-modules
  python-gobject-2
  python-imaging
  python-input-pad
  python-marisa
  python-repoze.lru
  python-setuptools
  python-zope.interface
  python2.7-minimal
  valac-0.24
  valac-0.24-vapi
  xfonts-utils
  xtrans-dev
  zlib1g:i386

Let’s inspect the generated files.

libkkc.install.log
 $ cat ../libkkc.install.log
usr/bin/kkc
usr/bin/kkc-package-data
usr/include/libkkc/libkkc.h
usr/lib/x86_64-linux-gnu/girepository-1.0/Kkc-1.0.typelib
usr/lib/x86_64-linux-gnu/libkkc.la
usr/lib/x86_64-linux-gnu/libkkc.so.2.0.0
usr/lib/x86_64-linux-gnu/pkgconfig/kkc-1.0.pc
usr/share/doc/libkkc/README.Debian
 ...
 ... (snip)
 ...
usr/share/libkkc/templates/libkkc-data/tools/genfilter.py
usr/share/libkkc/templates/libkkc-data/tools/sortlm.py
usr/share/locale/ja/LC_MESSAGES/libkkc.mo
usr/share/vala/vapi/kkc-1.0.deps
usr/share/vala/vapi/kkc-1.0.vapi

Let’s clean the source tree first.

 $ git reset --hard HEAD
HEAD is now at dd36e4b initial import of libkkc-0.3.2.tar.gz
 $ git clean -xfd
Removing Makefile
Removing autom4te.cache/
 ...
 ... (snip)
 ...
Removing tools/kkc
Removing tools/kkc-kkc.o
Removing tools/kkc-package-data

Let’s create the fresh source tree with the following package split plan.

binarypackage

type

-b option

libkkc2

lib

libkkc2

libkkc-utils

bin

-utils

libkkc2-dbg

dbg

libkkc2-dbg

libkkc-utils-dbg

dbg

-utils-dbg

libkkc-dev

dev

-dev

libkkc-common

data

-common:data

 
 $ debmake -b'libkkc2,-utils,libkkc2-dbg,-utils-dbg,-dev,-common:data'
D: /usr/bin/debmake started
D: PYTHONPATH = /usr/bin:/usr/lib/python3.4:/usr/lib/python3.4/plat-x86_64-...
I: set parameters
I: sanity check of parameters
I: pkg="libkkc", ver="0.3.2", rev="1"
I: *** start packaging in "libkkc-0.3.2". ***
I: provide libkkc_0.3.2.orig.tar.gz for non-native Debian package
I: pwd = "/path/to"
I: $ ln -sf libkkc-0.3.2.tar.gz libkkc_0.3.2.orig.tar.gz
 ...
 ... (snip)
 ...
I: skipping :: debian/libkkc2.install (file exists)
I: creating => debian/libkkc2.doc-base
I: creating => debian/libkkc-utils.install
I: creating => debian/libkkc-dev.install
I: creating => debian/libkkc-common.install
I: run "debmake -x3" to get more template files
I: $ wrap-and-sort

Let’s commit this result.

 $ git add -A .
 $ git commit -m debmake_template
[master d8b23d7] debmake_template
 27 files changed, 2860 insertions(+)
 create mode 100644 debian/README.Debian
 ...
 ... (snip)
 ...

This generates the following source tree. (Too large to list here.)

 $ tree
.
├── aclocal.m4
├── AUTHORS
├── autogen.sh
├── ChangeLog
├── compile
├── config.guess
├── config.h.in
├── config.sub
├── configure
├── configure.ac
├── COPYING
├── data
│   ├── Makefile.am
 ...
 ... (snip)
 ...
│   ├── user-segment-dictionary-bad2
│   ├── user-segment-dictionary-good
│   ├── user-sentence-dictionary-bad1
│   ├── user-sentence-dictionary-bad2
│   └── user-sentence-dictionary-good
└── tools
    ├── kkc.c
    ├── kkc-package-data.in
    ├── kkc.vala
    ├── kkc_vala.stamp
    ├── Makefile.am
    └── Makefile.in

95 directories, 438 files
 $ cd debian

Let’s make manual modifications to the files under the debian directory.

changelog
 $ vim changelog
 ...
 $ cat changelog
libkkc (0.3.2-1) unstable; urgency=low

  * First upload to debian archive (Closes: #715232)
  * Depends skkdic
  * Update debian/license

 -- Mitsuya Shibata <mty.shibata@gmail.com>  Wed, 26 Feb 2014 22:51:39 +090...
compat
 $ cat compat
9
control
 $ vim control
 ...
 $ cat control
Source: libkkc
Priority: extra
Maintainer: IME Packaging Team <pkg-ime-devel@lists.alioth.debian.org>
Uploaders: Mitsuya Shibata <mty.shibata@gmail.com>,
           Osamu Aoki <osamu@debian.org>
Build-Depends: autotools-dev,
               debhelper (>= 9),
               gobject-introspection,
               intltool,
               libgee-dev,
               libgirepository1.0-dev,
               libglib2.0-dev,
               libjson-glib-dev,
               libmarisa-dev,
               python-marisa,
               valac
Standards-Version: 3.9.5
Section: libs
Homepage: https://bitbucket.org/libkkc/libkkc/wiki/Home
Vcs-Git: git://anonscm.debian.org/pkg-ime/libkkc.git
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-ime/libkkc.git

Package: libkkc2
Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: libkkc-common, libkkc-data, skkdic, ${misc:Depends}, ${shlibs:Depe...
Description: Japanese Kana Kanji input library
 libkkc provides a converter from Japanese Kana-string to
 Kana-Kanji-mixed-string. It was named after kkc.el in GNU Emacs, a simple ...
 Kanji converter, while libkkc tries to convert sentences in a bit more com...
 way using N-gram language models.
 .
 This package provides the shared library for libkkc.

Package: libkkc-utils
Section: utils
Architecture: any
Multi-Arch: foreign
Depends: libkkc-data,
         libkkc2 (= ${binary:Version}),
         ${misc:Depends},
         ${shlibs:Depends}
Description: Japanese Kana Kanji input library - testing utility
 libkkc provides a converter from Japanese Kana-string to
 Kana-Kanji-mixed-string. It was named after kkc.el in GNU Emacs, a simple ...
 Kanji converter, while libkkc tries to convert sentences in a bit more com...
 way using N-gram language models.
 .
 This package provides the testing utility for libkkc.

Package: libkkc2-dbg
Section: debug
Architecture: any
Multi-Arch: same
Depends: libkkc2 (= ${binary:Version}), ${misc:Depends}
Description: Japanese Kana Kanji input library - library debugging symbols
 libkkc provides a converter from Japanese Kana-string to
 Kana-Kanji-mixed-string. It was named after kkc.el in GNU Emacs, a simple ...
 Kanji converter, while libkkc tries to convert sentences in a bit more com...
 way using N-gram language models.
 .
 This package contains the debugging symbols for the shared library of libk...

Package: libkkc-utils-dbg
Section: debug
Architecture: any
Multi-Arch: same
Depends: libkkc-utils (= ${binary:Version}), ${misc:Depends}
Description: Japanese Kana Kanji input library - utility debugging symbols
 libkkc provides a converter from Japanese Kana-string to
 Kana-Kanji-mixed-string. It was named after kkc.el in GNU Emacs, a simple ...
 Kanji converter, while libkkc tries to convert sentences in a bit more com...
 way using N-gram language models.
 .
 This package contains the debugging symbols for the testing utility of lib...

Package: libkkc-dev
Section: libdevel
Architecture: any
Multi-Arch: same
Depends: libkkc2 (= ${binary:Version}), ${misc:Depends}
Description: Japanese Kana Kanji input library - development files
 libkkc provides a converter from Japanese Kana-string to
 Kana-Kanji-mixed-string. It was named after kkc.el in GNU Emacs, a simple ...
 Kanji converter, while libkkc tries to convert sentences in a bit more com...
 way using N-gram language models.
 .
 This package provides the files necessary for compiling programs that
 depend on libkkc.

Package: libkkc-common
Section: utils
Architecture: all
Multi-Arch: foreign
Depends: ${misc:Depends}
Description: Japanese Kana Kanji input library - common data
 libkkc provides a converter from Japanese Kana-string to
 Kana-Kanji-mixed-string. It was named after kkc.el in GNU Emacs, a simple ...
 Kanji converter, while libkkc tries to convert sentences in a bit more com...
 way using N-gram language models.
 .
 This package provides common data such as typing rules for libkkc.
copyright
 $ vim copyright
 ...
 $ cat copyright
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: libkkc
Source: https://bitbucket.org/libkkc/libkkc/wiki/Home

Files: *
Copyright: 2011-2013 Daiki Ueno <ueno@gnu.org>
           2011-2013 Red Hat, Inc.
License: GPL-3.0+
 This program is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation, either version 3 of the License, or
 (at your option) any later version.
 .
 This program is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
 .
 You should have received a copy of the GNU General Public License
 along with this program.  If not, see <http://www.gnu.org/licenses/>.

Files: debian/*
 ...
 ... (snip)
 ...

Files: INSTALL
Copyright: 1994-2011 Free Software Foundation, Inc.
License: PERMISSIVE
 Copying and distribution of this file, with or without modification,
 are permitted in any medium without royalty provided the copyright
 notice and this notice are preserved.  This file is offered as-is,
 without warranty of any kind.
kkc.1
 $ vim kkc.1
 ...
 $ cat kkc.1
.\"                                      Hey, EMACS: -*- nroff -*-
.\" (C) Copyright 2013 Mitsuya Shibata <mty.shibata@gmail.com>,
.\"
.\" First parameter, NAME, should be all caps
.\" Second parameter, SECTION, should be 1-8, maybe w/ subsection
.\" other parameters are allowed: see man(7), man(1)
.TH KKC 1 "DEC 2013"
.\" Please adjust this date whenever revising the manpage.
.\"
.\" Some roff macros, for reference:
.\" .nh        disable hyphenation
.\" .hy        enable hyphenation
.\" .ad l      left justify
.\" .ad b      justify to both left and right margins
.\" .nf        disable filling
.\" .fi        enable filling
.\" .br        insert line break
.\" .sp <n>    insert n+1 empty lines
.\" for manpage-specific macros, see man(7)
.SH NAME
kkc \- a simple Kana Kanji converter
.SH SYNOPSIS
.B kkc
.I \fR[\fI help \fR|\fI decoder \fR|\fI context \fR]\fI
.RI [ OPTIONS ]
.SH DESCRIPTION
kkc converte from Kana-string to Kana-Kanji-mixed-string and list up
candidates.
.PP
Users can specify parameters through command line options. See
\fBkkc help\fP or \fBkkc command \-\-help\fP for the list of options.
.SH SEE ALSO
See /usr/share/doc/libkkc-utils/README for usage example.
install files
 $ echo 'usr/share/libkkc/rules/*' > libkkc-common.install
 $ echo 'usr/include/*'            > libkkc-dev.install
 $ echo 'usr/lib/*/lib*.so'        >>libkkc-dev.install
 $ echo 'usr/lib/*/pkgconfig/*'    >>libkkc-dev.install
 $ echo 'usr/share/vala/vapi/*'    >>libkkc-dev.install
 $ echo 'usr/bin/kkc'              > libkkc-utils.install
 $ echo 'usr/share/locale/'        >>libkkc-utils.install
 $ echo 'usr/lib/*/lib*.so.*'      >>libkkc2.install
 $ echo 'README'                   > libkkc-utils.docs
 $ echo 'debian/kkc.1'             > libkkc-utils.manpages
rules
 $ vim rules
 ...
 $ cat rules
#!/usr/bin/make -f
#DH_VERBOSE = 1

# In case you want to add more flags to the defaults, use
# the followings to harden via compiler options
# see FEATURE AREAS in dpkg-buildflags(1))
#export DEB_BUILD_MAINT_OPTIONS = hardening=+all
# see ENVIRONMENT in dpkg-buildflags(1))
# package maintainers to append CFLAGS
export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
# package maintainers to append LDFLAGS
export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

VALAFLAGS:=$(foreach w,$(CPPFLAGS) $(CFLAGS) $(LDFLAGS),-X $(w))

%:
        dh $@ --with autotools-dev,gir

override_dh_auto_configure:
        dh_auto_configure -- --disable-silent-rules

override_dh_strip:
        dh_strip -Xlibkkc-utils --dbg-package=libkkc2-dbg
        dh_strip -Xlibkkc2 --dbg-package=libkkc-utils-dbg

override_dh_test:
        : # NOP to avoid breakage
Remove unused template files
 $ rm -f clean
 $ rm -f libkkc2.examples
 $ rm -f libkkc2.info
 $ rm -f libkkc2.postinst
 $ rm -f libkkc2.postrm
 $ rm -f libkkc2.preinst
 $ rm -f libkkc2.prerm

Let’s record packaging result into VCS.

(Hmmm…. importing upstream with pristine-tar first is better but let’s not worry now.)

 $ cd ../
 $ git add -A .
 $ git commit -m initial_commit
[master 1fee795] initial_commit
 18 files changed, 539 insertions(+), 2783 deletions(-)
 delete mode 100644 debian/clean
 rewrite debian/control (74%)
 rewrite debian/copyright (87%)
 create mode 100644 debian/kkc.1
 create mode 100644 debian/libkkc-utils.docs
 create mode 100644 debian/libkkc-utils.manpages
 delete mode 100644 debian/libkkc2.examples
 delete mode 100644 debian/libkkc2.info
 delete mode 100644 debian/libkkc2.postinst
 delete mode 100644 debian/libkkc2.postrm
 ...
 ... (snip)
 ...
 delete mode 100644 debian/libkkc2.postinst
 delete mode 100644 debian/libkkc2.postrm
 delete mode 100644 debian/libkkc2.preinst
 delete mode 100644 debian/libkkc2.prerm
 rewrite debian/rules (72%)

Let’s build this package under the pdebuild command.

The first pdebuild
 $ pdebuild
dpkg-buildpackage: source package libkkc
dpkg-buildpackage: source version 0.3.2-1
 ...
 dpkg-source --before-build libkkc-0.3.2
 fakeroot debian/rules clean
make[3]: Entering directory '/path/to/libkkc-0.3.2'
--
dpkg-buildpackage: host architecture amd64
 fakeroot debian/rules clean
make[3]: Entering directory '/tmp/buildd/libkkc-0.3.2'
 ...
 debian/rules build
make[3]: Entering directory '/tmp/buildd/libkkc-0.3.2'
 ...
 fakeroot debian/rules binary
make[3]: Entering directory '/tmp/buildd/libkkc-0.3.2'
 ...
dpkg-gensymbols: warning: new libraries appeared in the symbols file: libkk...
dpkg-gensymbols: warning: debian/libkkc2/DEBIAN/symbols doesn't match compl...
--- debian/libkkc2.symbols (libkkc2_0.3.2-1_amd64)
+++ dpkg-gensymbolsvrvsOj       2014-06-12 15:36:11.710990854 +0000
@@ -0,0 +1,344 @@
+libkkc.so.2 libkkc2 #MINVER#
+ kkc_bigram_decoder_add_unknown_nodes@Base 0.3.2-1
+ kkc_bigram_decoder_backward_search@Base 0.3.2-1
+ kkc_bigram_decoder_build_trellis@Base 0.3.2-1
+ kkc_bigram_decoder_construct@Base 0.3.2-1
+ kkc_bigram_decoder_forward_search@Base 0.3.2-1
+ kkc_bigram_decoder_get_model@Base 0.3.2-1
 ...
  forking: rm -rf /var/cache/pbuilder/build//cow.25965
Restore source tree using VCS
 $ git reset --hard HEAD
HEAD is now at 1fee795 initial_commit
 $ git clean -d -f -x
 ...
 ... (snip)
 ...

Using mc, copy DEBIAN/symbols from the libkkc2_0.3.2-1_amd64.deb package to debian/libkkc2.symbols. (Of course, you can manually use the dpkg-deb command.)

Update debian/libkkc2.symbols
 $ vim debian/libkkc2.symbols
 ... (:%s/-1$//)
 ... (:wq)
 $ cat debian/libkkc2.symbols
libkkc.so.2 libkkc2 #MINVER#
 kkc_bigram_decoder_add_unknown_nodes@Base 0.3.2
 kkc_bigram_decoder_backward_search@Base 0.3.2
 kkc_bigram_decoder_build_trellis@Base 0.3.2
 kkc_bigram_decoder_construct@Base 0.3.2
 kkc_bigram_decoder_forward_search@Base 0.3.2
 ...
 ... (snip)
 ...
The second pdebuild
 $ pdebuild
dpkg-buildpackage: source package libkkc
dpkg-buildpackage: source version 0.3.2-1
 ...
 dpkg-source --before-build libkkc-0.3.2
 fakeroot debian/rules clean
make[3]: Entering directory '/path/to/libkkc-0.3.2'
--
dpkg-buildpackage: host architecture amd64
 fakeroot debian/rules clean
make[3]: Entering directory '/tmp/buildd/libkkc-0.3.2'
 ...
 debian/rules build
make[3]: Entering directory '/tmp/buildd/libkkc-0.3.2'
 ...
 fakeroot debian/rules binary
make[3]: Entering directory '/tmp/buildd/libkkc-0.3.2'
 ...
  forking: rm -rf /var/cache/pbuilder/build//cow.29800
The build result
 $ cd ..
 $ tree -L 1
.
├── libkkc-0.3.2
├── libkkc_0.3.2-1_amd64.build
├── libkkc_0.3.2-1_amd64.changes
├── libkkc_0.3.2-1.debian.tar.xz
├── libkkc_0.3.2-1.dsc
├── libkkc_0.3.2-1_source.changes
├── libkkc_0.3.2.orig.tar.gz -> libkkc-0.3.2.tar.gz
├── libkkc-0.3.2.tar.gz
├── libkkc2_0.3.2-1_amd64.deb
├── libkkc2-dbg_0.3.2-1_amd64.deb
├── libkkc.build-dep.log
├── libkkc.build.log
├── libkkc-common_0.3.2-1_all.deb
├── libkkc.depcheck.log
├── libkkc-dev_0.3.2-1_amd64.deb
├── libkkc.install.log
├── libkkc-utils_0.3.2-1_amd64.deb
└── libkkc-utils-dbg_0.3.2-1_amd64.deb

1 directory, 17 files

Let’s inspect the result.

The generated files of version 1.0 by the debuild command:
 $ cd ..
 $ tree -L 1
.
├── libkkc-0.3.2
├── libkkc_0.3.2-1_amd64.build
├── libkkc_0.3.2-1_amd64.changes
├── libkkc_0.3.2-1.debian.tar.xz
├── libkkc_0.3.2-1.dsc
├── libkkc_0.3.2-1_source.changes
├── libkkc_0.3.2.orig.tar.gz -> libkkc-0.3.2.tar.gz
├── libkkc-0.3.2.tar.gz
├── libkkc2_0.3.2-1_amd64.deb
├── libkkc2-dbg_0.3.2-1_amd64.deb
├── libkkc.build-dep.log
├── libkkc.build.log
├── libkkc-common_0.3.2-1_all.deb
├── libkkc.depcheck.log
├── libkkc-dev_0.3.2-1_amd64.deb
├── libkkc.install.log
├── libkkc-utils_0.3.2-1_amd64.deb
└── libkkc-utils-dbg_0.3.2-1_amd64.deb

1 directory, 17 files
The source package contents:
 $ tar -tJf libkkc_0.3.2-1.debian.tar.xz
debian/
debian/libkkc-utils.docs
debian/libkkc2.menu
debian/libkkc2.manpages
debian/compat
debian/libkkc2.links
debian/changelog
debian/watch
debian/libkkc2.install
debian/kkc.1
 ...
 $ tar -tzf libkkc-0.3.2.tar.gz
libkkc-0.3.2/
libkkc-0.3.2/missing
libkkc-0.3.2/tools/
libkkc-0.3.2/tools/kkc_vala.stamp
libkkc-0.3.2/tools/kkc.vala
libkkc-0.3.2/tools/Makefile.in
libkkc-0.3.2/tools/kkc-package-data.in
libkkc-0.3.2/tools/Makefile.am
libkkc-0.3.2/tools/kkc.c
libkkc-0.3.2/NEWS
 ...
The binary package contents:
 $ dpkg -c libkkc2_0.3.2-1_amd64.deb
drwxr-xr-x root/root ...  ./
drwxr-xr-x root/root ...  ./usr/
drwxr-xr-x root/root ...  ./usr/lib/
drwxr-xr-x root/root ...  ./usr/lib/x86_64-linux-gnu/
-rw-r--r-- root/root ...  ./usr/lib/x86_64-linux-gnu/libkkc.so.2.0.0
drwxr-xr-x root/root ...  ./usr/share/
drwxr-xr-x root/root ...  ./usr/share/doc/
drwxr-xr-x root/root ...  ./usr/share/doc/libkkc2/
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc2/changelog.gz
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc2/copyright
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc2/README.Debian
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc2/changelog.Debian.gz
drwxr-xr-x root/root ...  ./usr/share/menu/
-rw-r--r-- root/root ...  ./usr/share/menu/libkkc2
lrwxrwxrwx root/root ...  ./usr/lib/x86_64-linux-gnu/libkkc.so.2 -> libkkc....
 $ dpkg -c libkkc2-dbg_0.3.2-1_amd64.deb
drwxr-xr-x root/root ...  ./
drwxr-xr-x root/root ...  ./usr/
drwxr-xr-x root/root ...  ./usr/lib/
drwxr-xr-x root/root ...  ./usr/lib/debug/
drwxr-xr-x root/root ...  ./usr/lib/debug/.build-id/
drwxr-xr-x root/root ...  ./usr/lib/debug/.build-id/17/
-rw-r--r-- root/root ...  ./usr/lib/debug/.build-id/17/96418989f1ba19502b6d...
drwxr-xr-x root/root ...  ./usr/share/
drwxr-xr-x root/root ...  ./usr/share/doc/
drwxr-xr-x root/root ...  ./usr/share/doc/libkkc2-dbg/
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc2-dbg/changelog.gz
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc2-dbg/copyright
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc2-dbg/changelog.Debian.gz
 $ dpkg -c libkkc-common_0.3.2-1_all.deb
drwxr-xr-x root/root ...  ./
drwxr-xr-x root/root ...  ./usr/
drwxr-xr-x root/root ...  ./usr/share/
drwxr-xr-x root/root ...  ./usr/share/doc/
drwxr-xr-x root/root ...  ./usr/share/doc/libkkc-common/
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc-common/changelog.gz
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc-common/copyright
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc-common/changelog.Debian.gz...
drwxr-xr-x root/root ...  ./usr/share/libkkc/
 ...
 ... (snip)
 ...
-rw-r--r-- root/root ...  ./usr/share/libkkc/rules/default/keymap/hankaku-k...
-rw-r--r-- root/root ...  ./usr/share/libkkc/rules/default/keymap/wide-lati...
-rw-r--r-- root/root ...  ./usr/share/libkkc/rules/default/keymap/direct.js...
-rw-r--r-- root/root ...  ./usr/share/libkkc/rules/default/metadata.json
drwxr-xr-x root/root ...  ./usr/share/libkkc/rules/default/rom-kana/
-rw-r--r-- root/root ...  ./usr/share/libkkc/rules/default/rom-kana/default...
 $ dpkg -c libkkc-dev_0.3.2-1_amd64.deb
drwxr-xr-x root/root ...  ./
drwxr-xr-x root/root ...  ./usr/
drwxr-xr-x root/root ...  ./usr/include/
drwxr-xr-x root/root ...  ./usr/include/libkkc/
-rw-r--r-- root/root ...  ./usr/include/libkkc/libkkc.h
drwxr-xr-x root/root ...  ./usr/lib/
drwxr-xr-x root/root ...  ./usr/lib/x86_64-linux-gnu/
drwxr-xr-x root/root ...  ./usr/lib/x86_64-linux-gnu/pkgconfig/
-rw-r--r-- root/root ...  ./usr/lib/x86_64-linux-gnu/pkgconfig/kkc-1.0.pc
drwxr-xr-x root/root ...  ./usr/share/
drwxr-xr-x root/root ...  ./usr/share/doc/
drwxr-xr-x root/root ...  ./usr/share/doc/libkkc-dev/
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc-dev/changelog.gz
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc-dev/copyright
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc-dev/changelog.Debian.gz
drwxr-xr-x root/root ...  ./usr/share/vala/
drwxr-xr-x root/root ...  ./usr/share/vala/vapi/
-rw-r--r-- root/root ...  ./usr/share/vala/vapi/kkc-1.0.vapi
-rw-r--r-- root/root ...  ./usr/share/vala/vapi/kkc-1.0.deps
lrwxrwxrwx root/root ...  ./usr/lib/x86_64-linux-gnu/libkkc.so -> libkkc.so...
 $ dpkg -c libkkc-utils_0.3.2-1_amd64.deb
drwxr-xr-x root/root ...  ./
drwxr-xr-x root/root ...  ./usr/
drwxr-xr-x root/root ...  ./usr/bin/
-rwxr-xr-x root/root ...  ./usr/bin/kkc
drwxr-xr-x root/root ...  ./usr/share/
drwxr-xr-x root/root ...  ./usr/share/locale/
drwxr-xr-x root/root ...  ./usr/share/locale/ja/
drwxr-xr-x root/root ...  ./usr/share/locale/ja/LC_MESSAGES/
-rw-r--r-- root/root ...  ./usr/share/locale/ja/LC_MESSAGES/libkkc.mo
drwxr-xr-x root/root ...  ./usr/share/doc/
drwxr-xr-x root/root ...  ./usr/share/doc/libkkc-utils/
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc-utils/changelog.gz
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc-utils/copyright
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc-utils/changelog.Debian.gz
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc-utils/README
drwxr-xr-x root/root ...  ./usr/share/man/
drwxr-xr-x root/root ...  ./usr/share/man/man1/
-rw-r--r-- root/root ...  ./usr/share/man/man1/kkc.1.gz
 $ dpkg -c libkkc-utils-dbg_0.3.2-1_amd64.deb
drwxr-xr-x root/root ...  ./
drwxr-xr-x root/root ...  ./usr/
drwxr-xr-x root/root ...  ./usr/lib/
drwxr-xr-x root/root ...  ./usr/lib/debug/
drwxr-xr-x root/root ...  ./usr/lib/debug/.build-id/
drwxr-xr-x root/root ...  ./usr/lib/debug/.build-id/6a/
-rw-r--r-- root/root ...  ./usr/lib/debug/.build-id/6a/e0281cd5fd129fff74a5...
drwxr-xr-x root/root ...  ./usr/share/
drwxr-xr-x root/root ...  ./usr/share/doc/
drwxr-xr-x root/root ...  ./usr/share/doc/libkkc-utils-dbg/
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc-utils-dbg/changelog.gz
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc-utils-dbg/copyright
-rw-r--r-- root/root ...  ./usr/share/doc/libkkc-utils-dbg/changelog.Debian...

This package

The git repository (see http://anonscm.debian.org/gitweb/?p=collab-maint/debmake.git) is used to manage the development of the debmake package as follows.

 $ git clone https://alioth.debian.org/anonscm/git/collab-maint/debmake.git
 $ git checkout devel

The development of the debmake package is done on this devel branch:

  • Hack both in the upstream portion and under the debian/* directory, just like the native Debian package source tree.

  • Set the proper version strings before the release.

    • Update the version-rev string in the debian/changelog as if this is the non-native Debian package: dch -r

    • Update the version string in the debmake/__init__.py.

After everything is completed, you package the source as follows.

 $ cd test; make; make clean; cd -
 $ git add -A . ; git commit -m "Release ***"
 $ debmake -d -b:py3 -i pdebuild

The last command does 3 things:

  • Generate the upstream tarball. (-d == ./setup.py sdist)

  • Generate the source tree with debian/* copied from the VCS.

  • Build binary packages in the chroot. ("-i pdebuild")

Then you register the result into 3 branches of the git repository.

 $ gbp import-dsc --pristine-tar ../debmake_*-*.dsc

  • The upstream branch registers the upstream tarball contents.

  • The main branch registers the Debian source tree contents with debian/*.

  • The pristine-tar branch registers the *.orig.tar.gz file contents.

debmake(1) manpage

NAME

debmake - program to make the Debian source package

SYNOPSIS

debmake [-h] [-c | -k] [-n | -a package-version.orig.tar.gz | -d | -t ] [-p package] [-u version] [-r revision] [-z extension] [-b "binarypackage, …]" [-e foo@example.org] [-f "firstname lastname"] [-i "buildtool" | -j] [-l license_file] [-m] [-o file] [-q] [-s] [-v] [-w "addon, …"] [-x [01234]] [-y] [-Q]

DESCRIPTION

debmake helps to build the Debian package from the upstream source. Normally, this is done as follows:

  • The upstream tarball is downloaded as the package-version.tar.gz file.

  • It is untared to create many files under the package-version/ directory.

  • debmake is invoked in the package-version/ directory possibly without any arguments.

  • Files in the package-version/debian/ directory are manually adjusted.

  • dpkg-buildpackage (usually from its wrapper debuild or pdebuild) is invoked in the package-version/ directory to make debian packages.

Make sure to protect the arguments of the -b, -f, -l, and -w options from the shell interference by quoting them properly.

optional arguments:

-h, --help

show this help message and exit.

-c, --copyright

scan source for copyright+license text and exit.

  • -c: sinple output style

  • -cc: normal output style (similar to the debian/copyright file)

  • -ccc: debug output style

-k, --kludge

compare the debian/copyright file with the source and exit.

The debian/copyright file must be organized to list the generic file patterns before the specific exceptions.

  • -k: basic output style

  • -kk: verbose output style

-n, --native

make a native Debian source package without .orig.tar.gz. This makes the "3.0 (native)" format package.

If you are thinking to package a Debian specific source tree with debian/* in it into a native Debian package, please think otherwise. You can use "debmake -d -i debuild" or "debmake -t -i debuild" to make the "3.0 (quilt)" format non-native Debian package. The only difference is that the debian/changelog file must use the non-native version scheme: version-revision. The non-native package is more friendly to the downstream distributions.

-a package-version.tar.gz, --archive package-version.tar.gz

use the upstream source tarball directly. (-p, -u, -z: overridden)

The upstream tarball may be specified as package_version.orig.tar.gz and tar.gz for all cases may be tar.bz2, or tar.xz.

If the specified upstream tarball name contains uppercase letters, the Debian package name is generated by converting them to lowercase letters.

If the specified argument is the URL (http://, https://, or ftp://) to the upstream tarball, the upstream tarball is downloaded from the URL using wget or curl.

-d, --dist

run "make dist" equivalent first to generate upstream tarball and use it.

"debmake -d" is designed to run in the package/ directory hosting the upstream VCS with the build system supporting "make dist" equivalents. (automake/autoconf, Python distutils, …)

-t, --tar

run "tar" to generate upstream tarball and use it

"debmake -t" is designed to run in the package/ directory hosting the upstream VCS. 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. The generated tarball excludes the debian/ directory found in the upstream VCS. (It also excludes typical VCS directories: .git/ .hg/ .svn/ .CVS/)

-p package, --package package

set the Debian package name.

-u version, --upstreamversion version

set the upstream package version.

-r revision, --revision revision

set the Debian package revision.

-z extension, --targz extension

set the tarball type, extension=(tar.gz|tar.bz2|tar.xz) (alias: z, b, x)

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

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

Here, binarypackage is the binary package name; and 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)

  • dbg: Debug symbol package (any, same) (alias: db)

  • 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, debmake warns you.

-e foo@example.org, --email foo@example.org

set e-mail address.

The default is taken from the value of the environment variable $DEBEMAIL.

-f "firstname lastname", --fullname "firstname lastname"

set the fullname.

The default is taken from the value of the environment variable $DEBFULLNAME.

-i "buildtool", --invoke "buildtool"

invoke "buildtool" at the end of execution. "buildtool" may be "dpkg-buildpackage", "debuild", "pdebuild", "pdebuild --pbuilder cowbuilder", etc..

The default is not to execute any program.

-j, --judge

run dpkg-depcheck to judge build dependencies and identify file paths. Log files are in the parent directory.

  • package.build-dep.log: Log file for dpkg-depcheck.

  • package.install.log: Log file recording files in the debian/tmp directory.

-l "license_file,…", --license "license_file,…"

add formatted license text to the end of the debian/copyright file holding license scan results

The default is add COPYING and LICENSE and license_file needs to list only the additional file names all separated by ",".

-m, --monoarch

force packages to be non-multiarch.

-o file, --option file

read optional parameters from file. (This is not for everyday use.)

The file is sourced as the Python3 code at the end of para.py. For example, the package description can be specified by the following file.

para['desc'] = 'program short description'
para['desc_long'] = '''\
 program long description which you wish to include.
 .
 Empty line is space + .
 You keep going on ...
'''
-q, --quitearly

quit early before creating files in the debian/ directory.

-s, --spec

use upstream spec (setup.py for Python, etc.) for the package description.

-v, --version

show version information.

-w "addon,…", --with "addon,…"

add extra arguments to the --with option of the dh(1) command as addon in debian/rules.

The addon values are listed all separated by ",", e.g., -w "python2,autoreconf".

For Autotools based packages, setting autoreconf as addon forces to run "autoreconf -i -v -f" for every package building. Otherwise, autotools-dev as addon is used as default.

For Autotools based packages, if they install Python programs, python2 as addon is needed for packages with compat < 9 since this is non-obvious. But for setup.py based packages, python2 as addon is not needed since this is obvious and it is automatically set for the dh(1) command by the debmake command when it is required.

-x n, --extra n

generate extra configuration files as templates.

The number n changes which configuration templates are generated.

  • -x0: bare minimum configuration files. (default if these files exist already)

  • -x1: ,, + desirable configuration files. (default for new packages)

  • -x2: ,, + interesting configuration files. (recommended for experts, multi binary aware)

  • -x3: ,, + unusual configuration template files with the extra .ex suffix to ease their removal. (recommended for new users) To use these as configuration files, rename their file names into ones without the .ex suffix.

  • -x4: ,, + copyright file examples.

-y, --yes

force "yes" for all prompts. (without option: "ask [Y/n]"; doubled option: force "no")

-Q, --quiet

quiet tutorial comment lines marked with ### in template files

EXAMPLES

For a well behaving source, you can build a good-for-local-use installable single Debian binary package easily with one command. Test install of such a package generated in this way offers a good alternative to traditional "make install" to the /usr/local directory since the Debian package can be removed cleanly by the "dpkg -P …" command. Here are some examples of how to build such test packages. (These should work in most cases. If the -d does not work, try -t instead.)

For a typical C program source tree packaged with autoconf/automake:

  • debmake -d -i debuild

For a typical python module source tree:

  • debmake -s -d -b":python" -i debuild

For a typical python module in the package-version.tar.gz archive:

  • debmake -s -a package-version.tar.gz -b":python" -i debuild

For a typical perl module in the Package-version.tar.gz archive:

  • debmake -a Package-version.tar.gz -b":perl" -i debuild

HELPER PACKAGES

Packaging may require installation of some additional specialty helper packages.

  • Python3 program may require the dh-python package.

  • Autotools (Autoconf + Automake) build system may require autotools-dev or dh-autoreconf package.

  • Ruby program may require the gem2deb package.

  • Java program may require the javahelper package.

  • Gnome programs may require the gobject-introspection package.

  • etc.

CAVEAT

debmake is meant to provide template files for the package maintainer to work on. Comment lines started by ### are 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.

  • 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 of the “Debian Policy Manual”.

DEBUG

The character set in the environment variable $DEBUG determines the logging output level.

  • p: list all global parameters

  • d: list parsed parameters for all binary packages

  • f: input filename for the copyright scan

  • y: year/name split of copyright line

  • s: line scanner for format_state

  • b: content_state scan loop: begin-loop

  • m: content_state scan loop: after regex match

  • e: content_state scan loop: end-loop

  • c: print copyright section text

  • l: print license section text

  • a: print author/translator section text

  • k: sort key for debian/copyright stanza

  • n: scan result of debian/copyright (debmake -k)

Use this as:

 $ DEBUG=pdfbmeclak debmake ...

AUTHOR

Copyright © 2014 Osamu Aoki <osamu@debian.org>

LICENSE

MIT License

SEE ALSO

The debamake package provides following HTML documents:

Also, please read the original Debian New Maintainers' Guide provided by the the maint-guide package.

See also dpkg-source(1), deb-control(5), debhelper(7), dh(1), dpkg-buildpackage(1), debuild(1), quilt(1), dpkg-depcheck(1), pdebuild(1), pbuilder(8), cowbuilder(8), gbp-buildpackage(1), gbp-pq(1), and git-pbuilder(1) manpages.