People behind Debian: Joey Hess of debhelper fame

I decided recently to publish interviews from Debian contributors and I picked Joey Hess as my first target. He’s one of the few who have heavily influenced Debian by creating software that have become building blocks of the project, like the debian-installer (Joey uses the shorthand d-i to refer to it).

My questions are in bold, the rest is by Joey (except for the additional information that I inserted in italics).

Who are you?

Hello, I’m Joey Hess. I’m one of the oldtimers in Debian. Actually, I just checked, and there are still up to nineteen active Debian Developers who joined the project before I did, in 1996. I got started fairly young, and am “just” 34 years old.

I spend part of my time working with Lars Wirzenius, another Debian oldtimer, on Branchable. It makes it dead-easy for anyone to make a website that is built from Git, using my Ikiwiki engine to do wiki and blog style things. These days I spend the rest of my time working on free software, when I should really be looking for work to pay the bills.

What’s your biggest achievement within Debian or Ubuntu?

I guess I’m mostly known by Debian developers for writing debhelper and perhaps debconf. Probably founding the Debian Installer project has been a bigger impact for users. I’m fairly equally proud of all three projects. But while it might sound corny, I am more proud of the accumulation of all the smaller things done in the context of Debian. It’s more of a deep connection to the project. All the bugs fixed, and filed, and packages uploaded, and late night discussions, and just being a part of the larger project.

What are your plans for Debian Wheezy?

Hmm, I stopped thinking of Debian releases by code names back around Slink. 🙂 So, few specific plans for Wheezy. The main thing I would like to help make happen in Debian next is Constantly Usable Testing, and it transcends releases anyway. The only specific plans I have for Wheezy are that there will probably be a new debhelper compat level, and I hope d-i will finally switch to using git.

RH: You can learn more about “Constantly Usable Testing” in my article Can Debian offer a Constantly Usable Testing distribution?.

If you could spend all your time on Debian, what would you work on?

Getting Debian on all these computers that we carry around in our pockets and can’t easily run apt-get on and hack on. Phones that is. It’s a bigger problem than just Debian, but I think Debian needs to find a way to be part of the eventual solution. The FreedomBox concept at least hints at a way around the current situation with embedded computers in general.

What’s the biggest problem of Debian?

I believe that the biggest problem is institutional, social and technological inertia. Every specific case of something that frustrates me about Debian today can be traced back to that.

You contribute regularly to Debian mailing lists, yet I don’t remember any aggressive/frustrated mail of you. How do you manage that? Are you avoiding heated discussions?

Rats, sounds like all my wonderful flames of years past have been forgotten!

Seriously though, after I noticed thread patterns, I started trying to avoid participating in the bad patterns myself. Now I limit myself to one expression of an opinion, and I don’t care who gets the last word. If people can’t be convinced, it’s time to find another approach to the problem. Also, code talks.

Most of the programs you wrote for Debian are in Perl. Do you regret this choice?

I love that question! No, no regrets. My only concern is whether the language limits contributors or users. I have not seen Perl significantly limiting the use of anything except for debconf (we had to rewrite it in C for d-i). And I do not notice fewer contributions to my Perl-based code than to other code.

I do sometimes regret when someone tells me they had to learn or re-learn Perl to work on something I wrote. But while I’m enjoying writing new things in Haskell now, and while I hope it will mean less maintenance burden later, I don’t think using Haskell will make it easier for others to contribute to my programs. Anyway, for me the interesting thing about writing a program is the problem it solves and the decisions made doing it. Choice of language is one of the less interesting decisions.

Is there someone in Debian that you admire for his contributions?

Well, lots. You’re tempting me to throw a dart at a map. So arbitrarily, I’ll say Anthony Towns. We could all learn something from how he’s approached making big, fundamental changes, like introducing Testing, and making Debian Maintainers happen.

Thank you to Joey for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter and don’t miss further interviews. You can also follow along on, Twitter and Facebook.

PS: If you want to suggest me someone to interview, leave a comment or mail me.

How to create Debian packages with alternative compression methods

While gzip is the standard Unix tool when it comes to compression, there are other tools available and some of them are performing better than gzip in terms of compression ratio. This article will explain where you can make use of them in your Debian packaging work.

In the source package

A source package is composed of multiple files. The .dsc file is always uncompressed and it’s fine since it’s a small textual file. The upstream tarballs can be compressed with gzip (orig.tar.gz), bzip2 (orig.tar.bz2), lzma (orig.tar.lzma) or xz (orig.tar.xz), so choose the one that you want if upstream provides the tarball compressed with multiple tools. Put it at the right place and dpkg-source will automatically use it. Note however that packages using source format “1.0” are restricted to gzip, and the main Debian archive currently only allows gzip and bzip2 (xz might be allowed later) even if the source format “3.0 (quilt)” supports all of them.

The debian packaging files are provided either in a .diff.gz file for source format “1.0” (again only gzip is supported) or in a .debian.tar file for source format “3.0 (quilt)”. The latter tarball can be compressed with the tool of your choice, you just have to tell dpkg-source which one to use (see below, note that gzip is the default).

In a native package, dpkg-source must generate the main tarball and you can instruct it to use another tool than gzip with the --compression option. That option is usually put in debian/source/options:

# Use bzip2 instead of gzip
compression = "bzip2"
compression-level = 9

For “3.0 (quilt)” source packages, this option is not very useful as the debian tarball that gets compressed is usually not very large. But some maintainers like to use the same compression tool for the upstream tarball and the debian tarball, so you can use this option to harmonize both.

In native packages, it’s much more interesting: for instance the size of dpkg’s source package has been reduced of 30% by switching to bzip2, saving 2Mb of disk.

In the binary packages

.deb files also contain compressed tar archives and by default they use gzip as well:

$ ar t dpkg_1.15.9_i386.deb 

data.tar.gz is the archive that contains all the files to be installed and it’s the one that you can compress with another tool if you want. Again this is mostly interesting for (very) large packages where the size difference clearly justifies deviating from the default compression tool. Try it out and see how many megabytes you can shove. Another aspect that you must keep in mind is that those alternative tools might use important amount of memory to do their job, both for compression and decompression. So if your package is meant to be installed on embedded platforms, or if you want to build your package on low-end hardware with few memory, you might want to stick with gzip.

Now how do you change the compression tool? Easy, dpkg-deb supports a -Z option, so you just have to pass “-Zbzip2” for example. You can also pass “-z6” for example to change the compression level to 6 (it’s interesting because a lower compression level might require less memory depending on the tool used). The dpkg-deb invocation is typically hidden behind the call to dh_builddeb in your debian/rules so you have to replace that invocation with “dh_builddeb -- -Zbzip2“.

If you are using a debhelper 7 tiny rules files, you have to add an override like in this example:

	dh $@

	dh_builddeb -- -Zbzip2

If you are using CDBS, you have to set the variable DEB_DH_BUILDDEB_ARGS:

include /usr/share/cdbs/1/rules/

I hope you found this article helpful. Follow me on or on twitter.