Creating Debian packages on your own

Control Center

Although control contains only descriptive data, rules determines the course of the build packaging process, including compiling the source code. The rules file is a Makefile, like that used during the program compile. Figure 6 shows the version created by dh_make on the left, with the version from Ubuntu ffDiaporama on the right.

Figure 6: The "rules" file in the debian/ subdirectory is the key Makefile that drives the entire package build process.

I'll stay with the default version for now: Apart from the comments, it consists of the following equally short and cryptic lines:

%:
   dh $@

To understand these lines requires some basic knowledge of the GNU Make macroprocessor. In Makefiles, <name>: is a called a "target."

Thus, make install, for example, executes all shell commands that follow install: in the Makefile. The %: is a wildcard target that Make always executes, regardless of whether you specify make love or make war.

The $@ variable in the Makefile contains the name of the evoked targets. Therefore make -f rules dh_auto_configure calls on dh dh_auto_configure. Because rules is an executable file and the first shebang (#!) line selects Make as the interpreter, the direct call rules dh_auto_configure works. (The entry after the shebang (e.g., #!/bin/sh) refers to the interpreter of the code in this file. This mechanism is exclusive to Unix-like operating systems.)

Through the Makefile indirection that passes the target name with the dh parameter, dpkg-buildpackage then calls dh clean, dh build, and fakeroot dh binary. These three calls constitute the three main phases of package building: cleaning the source directory of possible previous build attempts, compiling the source code (./configure and make), and packaging the compiled files in a Debian.

All three dh calls start further helpers who perform the actual work. Their numbers alone reflect Debian's typical thoroughness: Three scripts remove remnants of any previous compiler run, four configure and compile the source code (./configure, make or their equivalents), and all of 42 are responsible for the make install call and creating the Debian package (Figure 7).

Figure 7: Using the Makefile rules file, dh_buildpackage makes three calls, starting a slew of helper scripts that compile the source code and build the Debian package.

A side note: dh binary and its subordinate helpers run under Fakeroot. Within the Fakeroot environment, they can write files of root ownership without having "real" root privileges. That's essential because files installed system-wide need to be root for security purposes. Fakeroot, however, prevents an erratic make install call from damaging the system.

Bank Shot

The reason for the indirect call to dh <parameter> via Makefile is evident from a look at the right-hand version of rules from the original ffDiaporama package in Figure 6. The targets beginning with override marked in red demonstrate how dh_<xxx> calls are replaced by shell commands: Every override_ target signals the build system to execute it instead of the target's dh_<xxx>.

The dh_auto_configure call replaces the original Ubuntu rules file with the qmake-qt4 ffDiaporama.pro command, the Qmake-specific equivalent of the familiar ./configure.

Maintainers might have considered this safer than relying on automatic creation. However, the automatic version created by dh_make also works: The help script apparently detects Qmake as the correct build system. There are cases, however, where only replacing Debian helpers with shell commands works.

Moreover, the dh_fixperms override combines console commands with Debian helpers instead of completely replacing them – a common approach in practice. In this specific case, an automated check for security vulnerabilities in file privileges does not allow write permissions to be added by hand before calling dh_fixperms.

The third override doesn't replace dh_install, but rather gives the helper script a calling parameter only. Which ones the Debian helpers understand as well as their role in the build system are described in the script manpages [7].

An important practical tip: If dh_auto_configure, for example, calls the correct configure command, but you still want to supply a parameter, then you can write an override_dh_auto_configure: target with the content dh_auto_configure -- --<parameter>. The helper script passes all parameters after the -- unchanged to the called command.