Some packaging tips for unmirrored dpkg repos
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/default.mk
SOURCE_NAME:=$(DEB_SOURCE)-$(DEB_VERSION_EPOCH_UPSTREAM)
SOURCE_TAR:=$(SOURCE_NAME).tar.gz
REMOTE_TAR:=https://github.com/LAStools/LAStools/archive/master.tar.gz
SOURCE_DIR:=LAStools-master/
clean:
rm -rf $(SOURCE_DIR) $(SOURCE_TAR) obj-$(DEB_HOST_MULTIARCH)
dh clean
build:
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)
override_dh_auto_configure:
dh_auto_configure -- -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH) -DBUILD_SHARED_LIBS=ON
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:
#!/usr/bin/dh-exec
/usr/lib/${DEB_HOST_MULTIARCH}/cmake
/usr/include
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/default.mk
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
todpkg-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
inoverride_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 https://github.com/LAStools/LAStools/archive/master.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