Common Mistakes

dh_make Example Files

When you use dh_make to create the initial "debianization", example files for various tasks are created in the debian/ directory. The templates have a .ex extension. If you want to use one, rename it to remove the extension. If you do not need it, remove it to keep the debian/ directory clean.

Changing the Original Tarball

There are two types of source packages, native and non-native. A native package is one that is specific to Ubuntu/Debian. It has the debian/ directory containing the packaging information and any changes to the source included in the tarball (usually <packagename>_<version>.tar.gz). Non-native packages are more common. A non-native package splits the source package into a <packagename>_<version>.orig.tar.gz tarball that is identical (hopefully including md5sum) to the source tarball downloaded from the project's homepage and a .diff.gz file that contains all the differences (debian/ directory and patches) from the original source tarball.

Here is a list of potential problems that can occur if you change the original tarball:

  1. Reproducibility

    If you take just the .diff.gz and .dsc, you or someone else has no means to reproduce the changes in the original tarball.

  2. Upgradeability

    It is much easier to upgrade to a new upstream (from the author) version if the .orig.tar.gz is preserved and there is a clear separation between the upstream source and the changes made to produce the Ubuntu source package.

  3. Debian to Ubuntu Synchronization

    Changing original tarballs makes it hard to automatically sync from Debian to Ubuntu. Normally, only the .diff.gz and .dsc files change within the same upstream version, since the .orig.tar.gz file is shared by all the Debian or Ubuntu revisions. It is much more difficult to sync if the md5sums of the .orig.tar.gz files are not the same.

  4. Usage of Revision Control for Debian package

    If you use svn (svn-buildpackage) to handle your Debian package, you usually don't store the original tarball inside. If someone else does a checkout, he'll need to get the original tarball separately. Other revision control systems can be used to track only the packaging files (debian/, etc.) and not the whole source. However, if the .orig.tar.gz is not the same, then obviously problems can occur.

  5. Security tracking

    Consider a situation where someone wants to introduce a backdoor/rootkit or other evil stuff. If the original tarball is intact, it can be scanned easily through the .diff.gz to see if the person who modified the package tried to do something evil. If the tarball has changed, however, you also need to check the differences between the tarball and the original source.

    [Note]

    You still have to trust the authors of the software not to do anything evil, but that is the case regardless of whether the original is changed.

  6. The .diff.gz

    The option to use the .diff.gz to reflect changes to the original tarball already exists, so it is easy to make changes without touching the original tarball.

It is acceptable to change the original tarball if one or more of the following hold true:

  • It contains non-free parts that cannot be redistributed. Remove those parts, and note it in the packaging. Often such packages use "dfsg" (which stands for Debian Free Software Guidelines) in the package name and/or versioning to indicate that non-free parts have been removed.

  • The authors only provide bzip2'ed source.

    • Just bunzip2 the .tar.bz2 and gzip -9 the resulting tar.

    • The md5sums of the .tar you provide and the original .tar must match!

    • Eventually provide a get-orig-source rule in debian/rules that does this conversion automatically.

  • Directly imported from SVN

    • Provide get-orig-source in debian/rules.

The following are not reasons to change the original tarball:

  • Wrong Directory Layout

    [Note]

    dpkg-source is quite flexible and manages to produce the correct directory layout even if:

    • The directory inside the tarball is not named <upstream>-<version>.

    • There is no subdirectory inside the tarball.

  • Files need to be removed to keep the .diff.gz small (e.g., files created by autotools). Everything that needs to be deleted should be removed in the clean rule. Since the .diff.gz is created with diff -u, you will not see removed files in the .diff.gz.

  • Files need to be modified. Files that need to be modified should to go into .diff.gz. That is its purpose!

  • Wrong permissions on files. You can use debian/rules to do this.

[Tip]

What do I do with an .orig.tar.gz that already includes a debian/ dir?

Do not repackage it. You can ask the author(s) to delete the debian/ dir and provide a diff.gz instead. This makes it easier to review their work, and it separates packaging from program source.

[Note]

It is always a good idea to contact the program's author(s) and ask if you may correct autoconf issues, directory layout, an outdated Free Software Foundation address in COPYRIGHT files, or other things that are not specific to the packaging but would be convenient for you so you do not need to "patch" the source in .diff.gz.

Copyright Information

The debian/copyright file should contain:

  • The licensing information for all files in the source. Sometimes author(s) put a license in COPYING but have different licensing information for some files in the source.

  • The copyright holder(s) and year(s).

  • The entire license unless it is one of the licenses found in /usr/share/common-licenses, in which case you should just include the preamble.

Prev  Up  Next
Updating Packages  Home  Chapter 4. Ubuntu Packaging