Why Debian Policy is important to package quality

Off the Beat: Bruce Byfield's Blog

Unless you are a Debian maintainer, you probably haven't read the Debian Policy Manual. However, when Ubuntu started promoting Snappy packages as a more secure solution to package management, the claim was challenged, not by reference to the technical structure of Debian packages, but to the Debian Policy Manual.

In fact, veteran Debian developer Josh Triplet went so far as to write that what makes "a real Debian package is Debian Policy.  Debian without the .deb format would still be Debian; Debian without Debian Policy would just be Sourceforge, or rpmfind" -- that is, a random collection of applications.

Other distributions, of course, have their own sets of standards for packages, including Fedora and Arch Linux. However, few, if any, are as detailed or as consistent as Debian Policy, or the framework of best practices that has been grown up around it.

Policy details
The process behind Debian Policy begins with the New Maintainer program, which is designed to teach members of the program how to operate, both technically and socially. Essentially, a would-be maintainer goes through an apprenticeship, working on bits of Debian before finding an existing developer to act as advocate, and demonstrating a knowledge of Debian's history and practices. Going through this process is the first step in Debian quality control.

The Debian Policy Manual itself is the definitive guide to Debian packages. It begins by describing the three sections of a Debian archive -- main, contrib, and non-free -- explaining that the distribution is the contents of main. However packages in contrib (free, but dependent on non-free software) and non-free (non-free licensed) are subject to the same process for quality control. In particular, all packages must meet the Debian Free Software Guidelines.

The policy goes on to describe how scripts should act, and the different files within a package and what they can and cannot do, and how they must be unpackaged and configured during installation and removed from the system. The manual goes on to describe the different types of dependencies, and how package breaks or conflicts should be handled, and how packages should interact with libraries.
Besides these main headings, other general details are given about the behavior of packages. Topics include:

• Where files should be placed in the directory hierarchy

• Packages must not overwrite /etc/crontab

• What virtual packages are and when to use them

• Environment variables must not be required to get reasonable defaults.

• Log files should be placed in /var/log and named for their packages, and be set up to rotate, so that the logs do not become too large.

• The formats for xservers, terminals, window managers, fonts, Perl programs and modules, games, man and info documents

• The structure needed to add applications to desktop menusFormat for xservers, terminals, window managers, fonts, Perl programs and modules, games, man and info documents

Only after give all this information does Debian Policy get down to the information that forms the core of other distributions' instructions, explaining how to build binary and source packages, and explaining the control and configuration files and a number of allowable alternatives.

This level of detail leaves little to chance. However, Debian also includes applications like lintian to check packages. By the time a package enters the unstable section of the archive and is tested for stability and quality, passes into testing -- the staging area for packages for the next stable release -- and finally is allowed into the next stable release, it has been not only assembled according to rigid guidelines, but also checked repeatedly. If you have ever wondered why Debian software versions can be far behind those of other distributions, a large part of the answer may be the process that every package goes through before being accepted.

Best practices
However, if Debian is rarely cutting edge, that may the price paid for consistency and quality. As Triplett writes,

"I know if I get a package from Debian that every piece of it will have a FOSS license.  Installing it will not break my system, or override my preferences.  The files within it will install into standard locations. The software within it will integrate properly with the rest of the distribution, and with the tools I expect to use to manage it.  And if anything goes wrong, I can easily report bugs in a consistent way, and expect reasonable handling of those bugs; I can also expect that the testing and stable distributions remain free of specific types of bugs."

As alternative package managements like Snappy are being discussed, the scope of the Debian Policy Manual is worth keeping in mind -- especially with the recent discussions of a universal package manager. Although technical details cannot be ignored, they are not everything that is needed.

Debian packages have become the dominant type of packages in Linux, used in over two-thirds of all distributions, not because they do anything particularly ingenious, but because they are built with a set of common practices that are more exacting than any other alternative.