Chapter 6. Best Packaging Practices

Table of Contents

6.1. Best practices for debian/rules
6.1.1. Helper scripts
6.1.2. Separating your patches into multiple files
6.1.3. Multiple binary packages
6.2. Best practices for debian/control
6.2.1. General guidelines for package descriptions
6.2.2. The package synopsis, or short description
6.2.3. The long description
6.2.4. Upstream home page
6.2.5. Version Control System location Vcs-Browser Vcs-*
6.3. Best practices for debian/changelog
6.3.1. Writing useful changelog entries
6.3.2. Common misconceptions about changelog entries
6.3.3. Common errors in changelog entries
6.3.4. Supplementing changelogs with NEWS.Debian files
6.4. Best practices for maintainer scripts
6.5. Configuration management with debconf
6.5.1. Do not abuse debconf
6.5.2. General recommendations for authors and translators Write correct English Be kind to translators Unfuzzy complete translations when correcting typos and spelling Do not make assumptions about interfaces Do not use first person Be gender neutral
6.5.3. Templates fields definition Type string password boolean select multiselect note text error Description: short and extended description Choices Default
6.5.4. Templates fields specific style guide Type field Description field String/password templates Boolean templates Select/Multiselect Notes Choices field Default field Default field
6.6. Internationalization
6.6.1. Handling debconf translations
6.6.2. Internationalized documentation
6.7. Common packaging situations
6.7.1. Packages using autoconf/automake
6.7.2. Libraries
6.7.3. Documentation
6.7.4. Specific types of packages
6.7.5. Architecture-independent data
6.7.6. Needing a certain locale during build
6.7.7. Make transition packages deborphan compliant
6.7.8. Best practices for .orig.tar.{gz,bz2,xz} files Pristine source Repackaged upstream source Changing binary files
6.7.9. Best practices for debug packages
6.7.10. Best practices for meta-packages

Debian's quality is largely due to the Debian Policy, which defines explicit baseline requirements which all Debian packages must fulfill. Yet there is also a shared history of experience which goes beyond the Debian Policy, an accumulation of years of experience in packaging. Many very talented people have created great tools, tools which help you, the Debian maintainer, create and maintain excellent packages.

This chapter provides some best practices for Debian developers. All recommendations are merely that, and are not requirements or policy. These are just some subjective hints, advice and pointers collected from Debian developers. Feel free to pick and choose whatever works best for you.

The following recommendations apply to the debian/rules file. Since debian/rules controls the build process and selects the files which go into the package (directly or indirectly), it's usually the file maintainers spend the most time on.

The rationale for using helper scripts in debian/rules is that they let maintainers use and share common logic among many packages. Take for instance the question of installing menu entries: you need to put the file into /usr/share/menu (or /usr/lib/menu for executable binary menufiles, if this is needed), and add commands to the maintainer scripts to register and unregister the menu entries. Since this is a very common thing for packages to do, why should each maintainer rewrite all this on their own, sometimes with bugs? Also, supposing the menu directory changed, every package would have to be changed.

Helper scripts take care of these issues. Assuming you comply with the conventions expected by the helper script, the helper takes care of all the details. Changes in policy can be made in the helper script; then packages just need to be rebuilt with the new version of the helper and no other changes.

Appendix A, Overview of Debian Maintainer Tools contains a couple of different helpers. The most common and best (in our opinion) helper system is debhelper. Previous helper systems, such as debmake, were monolithic: you couldn't pick and choose which part of the helper you found useful, but had to use the helper to do everything. debhelper, however, is a number of separate little dh_* programs. For instance, dh_installman installs and compresses man pages, dh_installmenu installs menu files, and so on. Thus, it offers enough flexibility to be able to use the little helper scripts, where useful, in conjunction with hand-crafted commands in debian/rules.

You can get started with debhelper by reading debhelper(1), and looking at the examples that come with the package. dh_make, from the dh-make package (see Section A.3.2, “dh-make), can be used to convert a vanilla source package to a debhelperized package. This shortcut, though, should not convince you that you do not need to bother understanding the individual dh_* helpers. If you are going to use a helper, you do need to take the time to learn to use that helper, to learn its expectations and behavior.

Big, complex packages may have many bugs that you need to deal with. If you correct a number of bugs directly in the source, and you're not careful, it can get hard to differentiate the various patches that you applied. It can get quite messy when you have to update the package to a new upstream version which integrates some of the fixes (but not all). You can't take the total set of diffs (e.g., from .diff.gz) and work out which patch sets to back out as a unit as bugs are fixed upstream.

Fortunately, with the source format “3.0 (quilt)” it is now possible to keep patches separate without having to modify debian/rules to setup a patch system. Patches are stored in debian/patches/ and when the source package is unpacked patches listed in debian/patches/series are automatically applied. As the name implies, patches can be managed with quilt.

When using the older source “1.0”, it's also possible to separate patches but a dedicated patch system must be used: the patch files are shipped within the Debian patch file (.diff.gz), usually within the debian/ directory. The only difference is that they aren't applied immediately by dpkg-source, but by the build rule of debian/rules, through a dependency on the patch rule. Conversely, they are reverted in the clean rule, through a dependency on the unpatch rule.

quilt is the recommended tool for this. It does all of the above, and also allows to manage patch series. See the quilt package for more information.

There are other tools to manage patches, like dpatch, and the patch system integrated with cdbs.

The following practices are relevant to the debian/control file. They supplement the Policy on package descriptions.

The description of the package, as defined by the corresponding field in the control file, contains both the package synopsis and the long description for the package. Section 6.2.1, “General guidelines for package descriptions” describes common guidelines for both parts of the package description. Following that, Section 6.2.2, “The package synopsis, or short description” provides guidelines specific to the synopsis, and Section 6.2.3, “The long description” contains guidelines specific to the description.

The package description should be written for the average likely user, the average person who will use and benefit from the package. For instance, development packages are for developers, and can be technical in their language. More general-purpose applications, such as editors, should be written for a less technical user.

Our review of package descriptions lead us to conclude that most package descriptions are technical, that is, are not written to make sense for non-technical users. Unless your package really is only for technical users, this is a problem.

How do you write for non-technical users? Avoid jargon. Avoid referring to other applications or frameworks that the user might not be familiar with — GNOME or KDE is fine, since users are probably familiar with these terms, but GTK+ is probably not. Try not to assume any knowledge at all. If you must use technical terms, introduce them.

Be objective. Package descriptions are not the place for advocating your package, no matter how much you love it. Remember that the reader may not care about the same things you care about.

References to the names of any other software packages, protocol names, standards, or specifications should use their canonical forms, if one exists. For example, 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.

If you are having problems writing your description, you may wish to send it along to and request feedback.

The long description is the primary information available to the user about a package before they install it. It should provide all the information needed to let the user decide whether to install the package. Assume that the user has already read the package synopsis.

The long description should consist of full and complete sentences.

The first paragraph of the long description should answer the following questions: what does the package do? what task does it help the user accomplish? It is important to describe this in a non-technical way, unless of course the audience for the package is necessarily technical.

The following paragraphs should answer the following questions: Why do I as a user need this package? What other features does the package have? What outstanding features and deficiencies are there compared to other packages (e.g., if you need X, use Y instead)? Is this package related to other packages in some way that is not handled by the package manager (e.g., this is the client for the foo server)?

Be careful to avoid spelling and grammar mistakes. Ensure that you spell-check it. Both ispell and aspell have special modes for checking debian/control files:

ispell -d american -g debian/control
aspell -d en -D -c debian/control

Users usually expect these questions to be answered in the package description:

  • What does the package do? If it is an add-on to another package, then the short description of the package we are an add-on to should be put in here.

  • Why should I want this package? This is related to the above, but not the same (this is a mail user agent; this is cool, fast, interfaces with PGP and LDAP and IMAP, has features X, Y, and Z).

  • If this package should not be installed directly, but is pulled in by another package, this should be mentioned.

  • If the package is experimental, or there are other reasons it should not be used, if there are other packages that should be used instead, it should be here as well.

  • How is this package different from the competition? Is it a better implementation? more features? different features? Why should I choose this package.

There are additional fields for the location of the Version Control System in debian/control.

Value of this field should be a string identifying unequivocally the location of the Version Control System repository used to maintain the given package, if available. * identify the Version Control System; currently the following systems are supported by the package tracking system: arch, bzr (Bazaar), cvs, darcs, git, hg (Mercurial), mtn (Monotone), svn (Subversion). It is allowed to specify different VCS fields for the same package: they will all be shown in the PTS web interface.

The information is meant to be useful for a user knowledgeable in the given Version Control System and willing to build the current version of a package from the VCS sources. Other uses of this information might include automatic building of the latest VCS version of the given package. To this end the location pointed to by the field should better be version agnostic and point to the main branch (for VCSs supporting such a concept). Also, the location pointed to should be accessible to the final user; fulfilling this requirement might imply pointing to an anonymous access of the repository instead of pointing to an SSH-accessible version of the same.

In the following example, an instance of the field for a Subversion repository of the vim package is shown. Note how the URL is in the svn:// scheme (instead of svn+ssh://) and how it points to the trunk/ branch. The use of the Vcs-Browser and Homepage fields described above is also shown.

  Source: vim
  Section: editors
  Priority: optional
  Vcs-Svn: svn://

The following practices supplement the Policy on changelog files.

The changelog entry for a package revision documents changes in that revision, and only them. Concentrate on describing significant and user-visible changes that were made since the last version.

Focus on what was changed — who, how and when are usually less important. Having said that, remember to politely attribute people who have provided notable help in making the package (e.g., those who have sent in patches).

There's no need to elaborate the trivial and obvious changes. You can also aggregate several changes in one entry. On the other hand, don't be overly terse if you have undertaken a major change. Be especially clear if there are changes that affect the behaviour of the program. For further explanations, use the README.Debian file.

Use common English so that the majority of readers can comprehend it. Avoid abbreviations, tech-speak and jargon when explaining changes that close bugs, especially for bugs filed by users that did not strike you as particularly technically savvy. Be polite, don't swear.

It is sometimes desirable to prefix changelog entries with the names of the files that were changed. However, there's no need to explicitly list each and every last one of the changed files, especially if the change was small or repetitive. You may use wildcards.

When referring to bugs, don't assume anything. Say what the problem was, how it was fixed, and append the closes: #nnnnn string. See Section 5.8.4, “When bugs are closed by new uploads” for more information.

The changelog entries should not document generic packaging issues (Hey, if you're looking for foo.conf, it's in /etc/blah/.), since administrators and users are supposed to be at least remotely acquainted with how such things are generally arranged on Debian systems. Do, however, mention if you change the location of a configuration file.

The only bugs closed with a changelog entry should be those that are actually fixed in the same package revision. Closing unrelated bugs in the changelog is bad practice. See Section 5.8.4, “When bugs are closed by new uploads”.

The changelog entries should not be used for random discussion with bug reporters (I don't see segfaults when starting foo with option bar; send in more info), general statements on life, the universe and everything (sorry this upload took me so long, but I caught the flu), or pleas for help (the bug list on this package is huge, please lend me a hand). Such things usually won't be noticed by their target audience, but may annoy people who wish to read information about actual changes in the package. See Section 5.8.2, “Responding to bugs” for more information on how to use the bug tracking system.

It is an old tradition to acknowledge bugs fixed in non-maintainer uploads in the first changelog entry of the proper maintainer upload. As we have version tracking now, it is enough to keep the NMUed changelog entries and just mention this fact in your own changelog entry.

Important news about changes in a package can also be put in NEWS.Debian files. The news will be displayed by tools like apt-listchanges, before all the rest of the changelogs. This is the preferred means to let the user know about significant changes in a package. It is better than using debconf notes since it is less annoying and the user can go back and refer to the NEWS.Debian file after the install. And it's better than listing major changes in README.Debian, since the user can easily miss such notes.

The file format is the same as a debian changelog file, but leave off the asterisks and describe each news item with a full paragraph when necessary rather than the more concise summaries that would go in a changelog. It's a good idea to run your file through dpkg-parsechangelog to check its formatting as it will not be automatically checked during build as the changelog is. Here is an example of a real NEWS.Debian file:

cron (3.0pl1-74) unstable; urgency=low

    The checksecurity script is no longer included with the cron package:
    it now has its own package, checksecurity. If you liked the
    functionality provided with that script, please install the new

 -- Steve Greenland <>  Sat,  6 Sep 2003 17:15:03 -0500

The NEWS.Debian file is installed as /usr/share/doc/package/NEWS.Debian.gz. It is compressed, and always has that name even in Debian native packages. If you use debhelper, dh_installchangelogs will install debian/NEWS files for you.

Unlike changelog files, you need not update NEWS.Debian files with every release. Only update them if you have something particularly newsworthy that user should know about. If you have no news at all, there's no need to ship a NEWS.Debian file in your package. No news is good news!

Maintainer scripts include the files debian/postinst, debian/preinst, debian/prerm and debian/postrm. These scripts take care of any package installation or deinstallation setup which isn't handled merely by the creation or removal of files and directories. The following instructions supplement the Debian Policy.

Maintainer scripts must be idempotent. That means that you need to make sure nothing bad will happen if the script is called twice where it would usually be called once.

Standard input and output may be redirected (e.g. into pipes) for logging purposes, so don't rely on them being a tty.

All prompting or interactive configuration should be kept to a minimum. When it is necessary, you should use the debconf package for the interface. Remember that prompting in any case can only be in the configure stage of the postinst script.

Keep the maintainer scripts as simple as possible. We suggest you use pure POSIX shell scripts. Remember, if you do need any bash features, the maintainer script must have a bash shebang line. POSIX shell or Bash are preferred to Perl, since they enable debhelper to easily add bits to the scripts.

If you change your maintainer scripts, be sure to test package removal, double installation, and purging. Be sure that a purged package is completely gone, that is, it must remove any files created, directly or indirectly, in any maintainer script.

If you need to check for the existence of a command, you should use something like

if [ -x /usr/sbin/install-docs ]; then ...

If you don't wish to hard-code the path of a command in your maintainer script, the following POSIX-compliant shell function may help:

pathfind() {
    for p in $PATH; do
        if [ -x "$p/$*" ]; then
            return 0
    return 1

You can use this function to search $PATH for a command name, passed as an argument. It returns true (zero) if the command was found, and false if not. This is really the most portable way, since command -v, type, and which are not POSIX.

While which is an acceptable alternative, since it is from the required debianutils package, it's not on the root partition. That is, it's in /usr/bin rather than /bin, so one can't use it in scripts which are run before the /usr partition is mounted. Most scripts won't have this problem, though.

Debconf is a configuration management system which can be used by all the various packaging scripts (postinst mainly) to request feedback from the user concerning how to configure the package. Direct user interactions must now be avoided in favor of debconf interaction. This will enable non-interactive installations in the future.

Debconf is a great tool but it is often poorly used. Many common mistakes are listed in the debconf-devel(7) man page. It is something that you must read if you decide to use debconf. Also, we document some best practices here.

These guidelines include some writing style and typography recommendations, general considerations about debconf usage as well as more specific recommendations for some parts of the distribution (the installation system for instance).

Most Debian package maintainers are not native English speakers. So, writing properly phrased templates may not be easy for them.

Please use (and abuse) mailing list. Have your templates proofread.

Badly written templates give a poor image of your package, of your work... or even of Debian itself.

Avoid technical jargon as much as possible. If some terms sound common to you, they may be impossible to understand for others. If you cannot avoid them, try to explain them (use the extended description). When doing so, try to balance between verbosity and simplicity.

Debconf templates may be translated. Debconf, along with its sister package po-debconf offers a simple framework for getting templates translated by translation teams or even individuals.

Please use gettext-based templates. Install po-debconf on your development system and read its documentation (man po-debconf is a good start).

Avoid changing templates too often. Changing templates text induces more work to translators which will get their translation fuzzied. A fuzzy translation is a string for which the original changed since it was translated, therefore requiring some update by a translator to be usable. When changes are small enough, the original translation is kept in PO files but marked as fuzzy.

If you plan to do changes to your original templates, please use the notification system provided with the po-debconf package, namely the podebconf-report-po, to contact translators. Most active translators are very responsive and getting their work included along with your modified templates will save you additional uploads. If you use gettext-based templates, the translator's name and e-mail addresses are mentioned in the PO files headers and will be used by podebconf-report-po.

A recommended use of that utility is:

cd debian/po && podebconf-report-po --call --languageteam --withtranslators --deadline="+10 days"

This command will first synchronize the PO and POT files in debian/po with the templates files listed in debian/po/ Then, it will send a call for new translations, in the mailing list. Finally, it will also send a call for translation updates to the language team (mentioned in the Language-Team field of each PO file) as well as the last translator (mentioned in Last-translator).

Giving a deadline to translators is always appreciated, so that they can organize their work. Please remember that some translation teams have a formalized translate/review process and a delay lower than 10 days is considered as unreasonable. A shorter delay puts too much pressure on translation teams and should be kept for very minor changes.

If in doubt, you may also contact the translation team for a given language (, or the mailing list.

This part gives some information which is mostly taken from the debconf-devel(7) manual page.

Template descriptions have two parts: short and extended. The short description is in the Description: line of the template.

The short description should be kept short (50 characters or so) so that it may be accommodated by most debconf interfaces. Keeping it short also helps translators, as usually translations tend to end up being longer than the original.

The short description should be able to stand on its own. Some interfaces do not show the long description by default, or only if the user explicitely asks for it or even do not show it at all. Avoid things like What do you want to do?

The short description does not necessarily have to be a full sentence. This is part of the keep it short and efficient recommendation.

The extended description should not repeat the short description word for word. If you can't think up a long description, then first, think some more. Post to debian-devel. Ask for help. Take a writing class! That extended description is important. If after all that you still can't come up with anything, leave it blank.

The extended description should use complete sentences. Paragraphs should be kept short for improved readability. Do not mix two ideas in the same paragraph but rather use another paragraph.

Don't be too verbose. User tend to ignore too long screens. 20 lines are by experience a border you shouldn't cross, because that means that in the classical dialog interface, people will need to scroll, and lot of people just don't do that.

The extended description should never include a question.

For specific rules depending on templates type (string, boolean, etc.), please read below.

Below are specific instructions for properly writing the Description (short and extended) depending on the template type.

Do NOT use empty default field. If you don't want to use default values, do not use Default at all.

If you use po-debconf (and you should, see Section, “Be kind to translators”), consider making this field translatable, if you think it may be translated.

If the default value may vary depending on language/country (for instance the default value for a language choice), consider using the special _Default type documented in po-debconf(7).

This section contains global information for developers to make translators' life easier. More information for translators and developers interested in internationalization are available in the Internationalisation and localisation in Debian documentation.

Internationalizing documentation is crucial for users, but a lot of labor. There's no way to eliminate all that work, but you can make things easier for translators.

If you maintain documentation of any size, it is easier for translators if they have access to a source control system. That lets translators see the differences between two versions of the documentation, so, for instance, they can see what needs to be retranslated. It is recommended that the translated documentation maintain a note about what source control revision the translation is based on. An interesting system is provided by doc-check in the debian-installer package, which shows an overview of the translation status for any given language, using structured comments for the current revision of the file to be translated and, for a translated file, the revision of the original file the translation is based on. You might wish to adapt and provide that in your VCS area.

If you maintain XML or SGML documentation, we suggest that you isolate any language-independent information and define those as entities in a separate file which is included by all the different translations. This makes it much easier, for instance, to keep URLs up to date across multiple files.

Some tools (e.g. po4a, poxml, or the translate-toolkit) are specialized in extracting the translatable material from different formats. They produce PO files, a format quite common to translators, which permits to see what needs to be retranslated when the translated document is updated.

Be sure to follow the Policy on documentation.

If your package contains documentation built from XML or SGML, we recommend you not ship the XML or SGML source in the binary package(s). If users want the source of the documentation, they should retrieve the source package.

Policy specifies that documentation should be shipped in HTML format. We also recommend shipping documentation in PDF and plain text format if convenient and if output of reasonable quality is possible. However, it is generally not appropriate to ship plain text versions of documentation whose source format is HTML.

Major shipped manuals should register themselves with doc-base on installation. See the doc-base package documentation for more information.

Debian policy (section 12.1) directs that manual pages should accompany every program, utility, and function, and suggests them for other objects like configuration files. If the work you are packaging does not have such manual pages, consider writing them for inclusion in your package, and submitting them upstream.

The manpages do not need to be written directly in the troff format. Popular source formats are Docbook, POD and reST, which can be converted using xsltproc, pod2man and rst2man respectively. To a lesser extent, the help2man program can also be used to write a stub.

Several specific types of packages have special sub-policies and corresponding packaging rules and practices:

  • Perl related packages have a Perl policy, some examples of packages following that policy are libdbd-pg-perl (binary perl module) or libmldbm-perl (arch independent perl module).

  • Python related packages have their python policy; see /usr/share/doc/python/python-policy.txt.gz in the python package.

  • Emacs related packages have the emacs policy.

  • Java related packages have their java policy.

  • Ocaml related packages have their own policy, found in /usr/share/doc/ocaml/ocaml_packaging_policy.gz from the ocaml package. A good example is the camlzip source package.

  • Packages providing XML or SGML DTDs should conform to the recommendations found in the sgml-base-doc package.

  • Lisp packages should register themselves with common-lisp-controller, about which see /usr/share/doc/common-lisp-controller/README.packaging.

There are two kinds of original source tarballs: Pristine source and repackaged upstream source.

The defining characteristic of a pristine source tarball is that the .orig.tar.{gz,bz2,xz} file is byte-for-byte identical to a tarball officially distributed by the upstream author.[5] This makes it possible to use checksums to easily verify that all changes between Debian's version and upstream's are contained in the Debian diff. Also, if the original source is huge, upstream authors and others who already have the upstream tarball can save download time if they want to inspect your packaging in detail.

There is no universally accepted guidelines that upstream authors follow regarding to the directory structure inside their tarball, but dpkg-source is nevertheless able to deal with most upstream tarballs as pristine source. Its strategy is equivalent to the following:

  1. It unpacks the tarball in an empty temporary directory by doing

    zcat path/to/packagename_upstream-version.orig.tar.gz | tar xf -
  2. If, after this, the temporary directory contains nothing but one directory and no other files, dpkg-source renames that directory to packagename-upstream-version(.orig). The name of the top-level directory in the tarball does not matter, and is forgotten.

  3. Otherwise, the upstream tarball must have been packaged without a common top-level directory (shame on the upstream author!). In this case, dpkg-source renames the temporary directory itself to packagename-upstream-version(.orig).

You should upload packages with a pristine source tarball if possible, but there are various reasons why it might not be possible. This is the case if upstream does not distribute the source as gzipped tar at all, or if upstream's tarball contains non-DFSG-free material that you must remove before uploading.

In these cases the developer must construct a suitable .orig.tar.{gz,bz2,xz} file themselves. We refer to such a tarball as a repackaged upstream source. Note that a repackaged upstream source is different from a Debian-native package. A repackaged source still comes with Debian-specific changes in a separate .diff.gz or .debian.tar.{gz,bz2,xz} and still has a version number composed of upstream-version and debian-version.

There may be cases where it is desirable to repackage the source even though upstream distributes a .tar.{gz,bz2,xz} that could in principle be used in its pristine form. The most obvious is if significant space savings can be achieved by recompressing the tar archive or by removing genuinely useless cruft from the upstream archive. Use your own discretion here, but be prepared to defend your decision if you repackage source that could have been pristine.

A repackaged .orig.tar.{gz,bz2,xz}

  1. should be documented in the resulting source package. Detailed information on how the repackaged source was obtained, and on how this can be reproduced should be provided in debian/copyright. It is also a good idea to provide a get-orig-source target in your debian/rules file that repeats the process, as described in the Policy Manual, Main building script: debian/rules.

  2. should not contain any file that does not come from the upstream author(s), or whose contents has been changed by you.[6]

  3. should, except where impossible for legal reasons, preserve the entire building and portablility infrastructure provided by the upstream author. For example, it is not a sufficient reason for omitting a file that it is used only when building on MS-DOS. Similarly, a Makefile provided by upstream should not be omitted even if the first thing your debian/rules does is to overwrite it by running a configure script.

    (Rationale: It is common for Debian users who need to build software for non-Debian platforms to fetch the source from a Debian mirror rather than trying to locate a canonical upstream distribution point).

  4. should use packagename-upstream-version.orig as the name of the top-level directory in its tarball. This makes it possible to distinguish pristine tarballs from repackaged ones.

  5. should be gzipped or bzipped with maximal compression.

A debug package is a package with a name ending in -dbg, that contains additional information that gdb can use. Since Debian binaries are stripped by default, debugging information, including function names and line numbers, is otherwise not available when running gdb on Debian binaries. Debug packages allow users who need this additional debugging information to install it, without bloating a regular system with the information.

It is up to a package's maintainer whether to create a debug package or not. Maintainers are encouraged to create debug packages for library packages, since this can aid in debugging many programs linked to a library. In general, debug packages do not need to be added for all programs; doing so would bloat the archive. But if a maintainer finds that users often need a debugging version of a program, it can be worthwhile to make a debug package for it. Programs that are core infrastructure, such as apache and the X server are also good candidates for debug packages.

Some debug packages may contain an entire special debugging build of a library or other binary, but most of them can save space and build time by instead containing separated debugging symbols that gdb can find and load on the fly when debugging a program or library. The convention in Debian is to keep these symbols in /usr/lib/debug/path, where path is the path to the executable or library. For example, debugging symbols for /usr/bin/foo go in /usr/lib/debug/usr/bin/foo, and debugging symbols for /usr/lib/ go in /usr/lib/debug/usr/lib/

The debugging symbols can be extracted from an object file using objcopy --only-keep-debug. Then the object file can be stripped, and objcopy --add-gnu-debuglink used to specify the path to the debugging symbol file. objcopy(1) explains in detail how this works.

The dh_strip command in debhelper supports creating debug packages, and can take care of using objcopy to separate out the debugging symbols for you. If your package uses debhelper, all you need to do is call dh_strip --dbg-package=libfoo-dbg, and add an entry to debian/control for the debug package.

Note that the debug package should depend on the package that it provides debugging symbols for, and this dependency should be versioned. For example:

Depends: libfoo (= ${binary:Version})

[5] We cannot prevent upstream authors from changing the tarball they distribute without also incrementing the version number, so there can be no guarantee that a pristine tarball is identical to what upstream currently distributing at any point in time. All that can be expected is that it is identical to something that upstream once did distribute. If a difference arises later (say, if upstream notice that they weren't using maximal compression in their original distribution and then re-gzip it), that's just too bad. Since there is no good way to upload a new .orig.tar.{gz,bz2,xz} for the same version, there is not even any point in treating this situation as a bug.

[6] As a special exception, if the omission of non-free files would lead to the source failing to build without assistance from the Debian diff, it might be appropriate to instead edit the files, omitting only the non-free parts of them, and/or explain the situation in a README.source file in the root of the source tree. But in that case please also urge the upstream author to make the non-free components easier separable from the rest of the source.