Chapter 1. Preface

If you are a somewhat experienced Debian user ^[1], you may have encountered the 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 want to create a Debian package to fulfill these needs and share your work with the community, you are the target audience of this guide as a prospective Debian maintainer. ^[2] Welcome to the Debian community.

Debian has many social and technical rules and conventions to follow, as it is a large volunteer organization with a rich history. Debian has also developed an extensive array of packaging and archive maintenance tools to build consistent sets of binary packages that address many technical objectives:

packages have clearly specified package dependencies and patches and build correctly from scratch in a clean build environment (“Section 6.6, “debian/control file””, “Section 6.9, “debian/patches/* files””, “Section 4.6, “sbuild setup””)
packages build across many architectures (“Section 9.3, “Variables for debian/rules””)
builds are reproducible (“Section 10.7, “Reproducible build””)
multiarch is supported (“Section 10.10, “Multiarch””)
bootstrapping new architectures is possible (“Section 10.5, “Bootstrapping””)
builds use specific compiler flags to harden security (“Section 10.6, “Compiler hardening””)
packages are split optimally into multiple binary packages (“Section 10.11, “Split of a Debian binary package””)
library names and contents are managed to ensure smooth transitions on upgrades (“Section 10.18, “Library transition””)
installations use interactive prompts correctly (if at all) (“Section 10.22, “debconf””)
continuous integration is used to ensure quality (“Section 10.4, “Continuous integration””)
…

These factors can be overwhelming for many new prospective Debian maintainers. This guide aims to provide entry points to help them get started. It covers the following:

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 with minimal effort.
Examples of making Debian packages in typical scenarios.

The author recognized the limitations of updating the original “New Maintainers' Guide” with the dh-make package and decided to create an alternative tool with accompanying documentation to address modern requirements such as multi-arch. This resulted in the debmake package, initially released as version 4.0 in 2013. The current debmake version is 4.5.1. It comes with this updated “Guide for Debian Maintainers” in the debmake-doc package (version: 1.22-1). (In 2016, dh-make was ported from Perl to Python with updated features.)

Many chores and tips have been integrated into the debmake command allowing this guide to be terse. This guide also offers many packaging examples for you to get started.

	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. While some may seem irrelevant to you, please be patient. Certain corner cases are omitted, and some topics are only covered through external references. These are intentional choices to keep this guide simple and maintainable.

^[1]You need to know a little about Unix programming, but you don’t need to be an expert. You can learn about basic Debian system handling from the “Debian Reference”. It also contains pointers for learning about Unix programming.

^[2]If you’re not interested in sharing the Debian package, you can address your local needs by compiling and installing the fixed upstream source package into /usr/local/.


Guide for Debian Maintainers		Chapter 2. Overview