Debian package has one wart I’ve been trying to fight with:

The entire package mechanism assumes your source code is a managed mirror of upstream.

For those of us who don’t want to mirror upstream and apply debian packaging rebases and patches, there’s a way to pull from upstream (especially github branch/tag archives) and produce a self-contained and self-cleaning build.

I’ll use LAStools as my example since this is what I just finished packaging:

#!/usr/bin/make -f

include /usr/share/dpkg/


        rm -rf $(SOURCE_DIR) $(SOURCE_TAR) obj-$(DEB_HOST_MULTIARCH)
        dh clean

        wget -O $(SOURCE_TAR) $(REMOTE_TAR)
        tar -xaf $(SOURCE_TAR)
        for i in $$(cat debian/patches/series); do patch -p1 < debian/patches/$$i; done
        dh build --buildsystem=cmake --sourcedir=$(SOURCE_DIR)

        dh $@  --sourcedir=$(SOURCE_DIR)


This rules file will download the master.tar.gz archive from github, extract it to produce a ./LAStools-master, patch with the necessary cmake and security patches in debian/patches (similar to using quilt), then build in the LAStools-master subdirectory using cmake.

If you’re using multiarch (you should be), you can use dh-exec capabilities to generate multiarch-compatible package.install files. dh-exec is less necessary in compat 13, but that isn’t finished being rolled out yet to downstream releases like Ubuntu.

Here’s what i produced to make the cmake files show up in the liblastools-dev package:


Just mark the debian/liblastools-dev.install file as exectuable and dh-exec will take care of the rest.

A few callouts:

  • I used 3.0 (custom) in debian/source/format, but I can’t say that was absolutely necessary for this build setup
  • make sure you use include /usr/share/dpkg/ in your makefile to get access to common packaging variables
  • Quilt (via dpkg-source) will automatically apply the patches listed by debian/patches/series, but that only works if you’re using importing from a .dsc file meaning somebody has already generated a debian package archive ahead of time.
  • Not all of us give a hoot about producing Debian hosting conformant packages with signing, etc, so you can pass --no-sign to dpkg-buildpackage to skip that step.
  • CMake build system isn’t set to produce shared libs by default so make sure to set -DBUILD_SHARED_LIBS=ON in override_dh_auto_configure
  • Since I wanted an atomically rebuild-able library I overrode the default build steps for dpkg-buildpackage
    • dpkg-buildpackage -Tclean,build,binary,clean --no-sign
  • I still had to go through the original rigamarole of producing a base package, getting quilt/dquilt configured and producing a patch series, etc.

Here’s what I did to create the initial project structure to prepare for quilt patching:

$ wget -O lastools-0.1.0.tar.gz
$ mkdir lastools-0.1.0; cd lastools-0.1.0
$ dh_make -f ../lastools-0.1.0.tar.gz
$ tar -xaf ../lastools-0.1.0.tar.gz
$ dquilt new 1.patch
... apply changes
$ dquilt refresh
$ dquilt new 2.patch
$ dquilt refresh
... etc

This gave me the initial debian/ files to work with. From there, updating debian/rules, debian/control, debian/changelog, debian/source/format to produce a downloaded build was all that was necessary. All the other generated files can be removed except for debian/patches as this is what Quilt produces and you’ll want to re-apply them for your repeatable build.

You’ll want to make sure to manage your changelog, I don’t need to do that yet for this release so we’ll see how to get upstream comments in from the remote archive at a later date. In general, probably don’t care about this too much beyond just annotating releases