Once you've downloaded, modified and built a Debian package, you usually feel that you could keep doing it, since it's so easy.

And it's just like that, but even if the BuildingTutorial is a good introduction to modifying Debian packages, there were some things that were left out on purpose, to keep it simple. So, here you'll find some extra tips to take full advantage of some of the many Debian tools.

Useful packages

Although they might not be build dependencies, there's a bunch of useful packages that anyone interested in helping Debian development should have installed:

• build-essential: includes the essential packages for building your own ones, this is probably already installed in your system, but it never hurts to check.
• devscripts: lots of useful scripts for Debian Development (including: dch, debuild, uscan, uupdate and many others).
• lintian and linda: two package checkers, that verify the built package is in good shape regarding Debian Policy.
• diff, patch and patchutils: utilities for working with patches.

And here's a useful command line, to copy and paste:

  apt-get install build-essential devscripts lintian linda diff patch patchutils

Using the changelog

The debian/changelog file is one of the important files in the debian directory. Let's take one changelog entry as an example:

   control-center (1:2.8.1-3) unstable; urgency=low

     * debian/rules:
       - Corrected erroneous line responsible for not including the .desktop
       files (Closes: #274401)
     * debian/patches:
       - Suppressed 'Text Editor' in the "preferred applications" as it's useless
       with the new mime type system.

    -- Arnaud Patard <arnaud.patard@rtp-net.org>  Thu, 25 Nov 2004 21:16:04 +0100

There are many things to notice in this entry: in the first line you have the name and version of the source package, also the distribution to which it is initially uploaded to (unstable), and the urgency level (this is used by Debian bots to determine when the package is ready to enter testing).

Then, we have a bulleted list with the files that were changed and a very brief summary of the reasons for the changes. Note the (Closes #274401), this is used by Debian bugs bot to automatically close bugs.

Finally, we can see the name and email of the last person to change the package and the date on which it was changed.

Now, to edit the changelog, if you have installed devscripts you'll have a nifty command dch that prefills a lot of this information and opens your preferred editor. Although you can edit everything manually if you want, I recommend using dch.

Important: when you first start modifying a package, you'll want to make a new version of it, so that you can differentiate it from the original one. So, the first time you are about to edit a changelog entry, you should do

  dch -i

This will add a whole new entry, incrementing the version number and letting you write which files you modified. After that, you can always add more info about your changes by just using dch.

Building the source package

When you do debian/rules binary you just build the binary package, the one that you want to install on your system. But in many cases you want to also build the source package (which is actually composed of three files: package_version.orig.tar.gz, package_version.diff.gz and package_version.dsc).

To do this there are lots of tools. Here, we'll be using dpkg-buildpackage that comes with the dpkg-dev package (part of build-essential).

Provided you already modified the package and the package's changelog, you'll build it by doing:

   dpkg-buildpackage -rfakeroot

(There are many option to pass to dpkg-buildpackage, -S for example, will only build the source package, -tc will clean the compiled files after making the package, etc. See man dpkg-buildpackage for more info)

Once you've done this, you'll find a new trio of files in your parent directory, that will have almost the same name as the ones you downloaded but with a change in the version number.

Using interdiff

If you've built a package, incremented the version number in the changelog file, and now you have two sets of three files (two source packages) you can gather what the changes between versions were very easily by using interdiff:

   interdiff -z package_oldversion.diff.gz package_newversion.diff.gz > your.patch

After running this command you can inspect the contents of your.patch, it should contain everything that you changed to the package. If you are solving a bug in the Debian BTS, this is what you should send to the bug number.

Note that interdiff only makes sense when you haven't changed the upstream source (this is to say, the package_version.orig.tar.gz has to be the same).

Using lintian and linda

Not all Debian packages comply perfectly with Debian's policy. Sometimes this is due to the policy getting quickly updated, sometimes this is because of lack of time from the maintainer, sometimes because it's not easy for certain software to be totally compliant.

In any case, these tools provide us with an easy way to find problems in Debian packages. Using them is easy: you just run them against the .diff.gz and .dsc files of your source package.

Depending on the package, you could get no messages, some messages or a lot of messages. These messages are usually brief and not always will you know what they mean, but many times they'll point you to the problematic part of the package.

Of course, these tools are just an aid, not a replacement to actually reading Debian's policy.

Getting help

If you get stuck in what you are doing, there's lots of places where you can get help.

• You can go to the Debian Developer's corner where you can find lots of information online.
• You can ask online at irc.freenode.net, on #debian-women, #debian-mentors, #debian-bugs or #debian-devel (choose the one that is closer to what you are doing).
• Or you can ask on one of the many Debian Mailing Lists.