How was the experience
This past week I had holidays and, because of a set of circumstances, I didn’t go anywere. Given the time at hand I decided to try caddy server which is a nice little server written in go with lets encrypt integration, written in Go.
Now, the end result is that I did not manage to get it into my server, but the reason is not the software itself.
Many Go softwares lack per distribution packages and, after trying to package caddy, I cannot blame them at all.
For those not familiar with the nature of Go, it compiles static binaries, this has its pros and cons but one pro that we cannot deny is that, as a distribution mean, a single binary is very easy to distribute.
I had only re-packaged debian binaries before so I gave it a shot, how hard could it be?
I discovered that the tools available, at least for my distro of choice (Ubuntu) are quite unfriendly. The basic packaging experience suggested makes use of bazaar, bazaar plugins, launchpad and debhelpers. The documentation is mostly referential (ie, more man pages than howtos/tutorials) and, if I where to create a package for official distribution, I would have had to find a way to learn all the internals and politics of it myself. Learning how to “quickly” package is not something very possible unless you want to end with a set of knowledge full of gaps.
I finally end up what is called a native package, which means that it is not based on an upstream source (which is a lie but I found no proper way to lay out my project and dependencies in a way that dpkg helpers wouldn’t complain in very unhelpful ways)
Finally I end up with a package that satisfies me (and works on any amd64, i386 and arm64 from trusty on) the ppa declares to support only trusty, vivid and xenial because these are the only distributions that have Go 1.6, required for the build (as a rule a package can only be compiled by launchpad for a distro that has packages for all dependencies) but you could just download the .deb file and put it wherever you like since its a static file (and some basic config which works in any version of Ubuntu).
Some things that are left to fix:
- Make the package use the Quilt format instead of Native.
- Make the config for systemd be automatic and not manual (currently the only package.xxx files available in the package are for upstart and systemd service is being installed by hand.
- Add man pages.
- Find how is vendoring supposed to be treated in go packages and use the go debhelper (currently I actually compile the package by hand and bundle the vendored packages using rogpeppe’s godeps.
If you feel like lending a hand, all patches are welcome:
- This is the PPA
- This is the bzr repo for Wily and newer
- This is the bzr repo for trusty Note there are two repos because debian control file (what tells the env how it should look to compile this) does not support having optional build dependencies and since go 1.6 is not golang-go in Trusty but a proposed package called golang1.6 I had to write different controls.
What could be improved
I am pretty sure that the debian packaging system is quite complete and is a very powerful tool but its documentation is not laid out in a way that makes this process easy to onboard (there is fpm for some languages, not Go sadly).
What would help? A simple tutorial on:
- What is expected.
- What is the required file for systemd
- What should the files have with a real life example (they use the hello package in many, which is a poor example)
- How to approach it for different languages.
- What do the current helper tools do under the hood (I spent a good time trying to discover where was the fakeroot builder taking “upstream” gz from).
Why don’t I do it? I cargo culted most of the process and, even though I could describe it a bit, I am sure I break every single debian packaging rule.
Oh, the reason I did not get it into my server? I spent the whole time I had creating the PPA.