This page is about packaging golang.org libraries in Debian.

Facts

• The go compiler (gc) needs to have the source code of a package available when compiling code that uses it. E.g. if your code uses github.com/mstap/godebiancontrol, gc needs $GOPATH/src/github.com/mstap/godebiancontrol (can that be fixed?)

• Perl uses libXX-perl for package names (e.g. libnet-inet6glue-perl for Net::INET6Glue), while Ruby switched to ruby-xx (e.g. ruby-tioga). TODO: Is there some rationale behind either decision? Which is “better”?

• Both Perl and Ruby use /usr/lib/{perl,ruby} and store source as well as shared objects there.

Package naming

For github.com/mstap/godebiancontrol (which contains "go" already), the resulting Debian package name is golang-godebiancontrol.

Where to store go src/pkg data?

• /usr/src: The FHS says this is for source, but we also store the compiled binaries.

• /usr/lib/go: This directory is used by golang-go. The included src is a symlink to /usr/share/go/src. I’m not sure whether it’s a good idea to mix the namespace of $GOROOT and $GOPATH.

• /usr/lib/golang: Too close to /usr/lib/go?

• /usr/lib/gocode: Seems fine to me.

Multi-Arch/cross-compiling

golang-go is currently available for amd64 (linux_amd64), armel (linux_arm), armhf (linux_arm), i386 (linux_386).

Note that the identifier Go uses is “linux_arm” for both armel and armhf while the files differ:

Binary files /tmp/armhf/usr/lib/go/pkg/linux_arm/unicode.a and /tmp/armel/usr/lib/go/pkg/linux_arm/unicode.a differ

Multi-arch in itself doesn’t make sense: gc produces static binaries, so to run a program that was compiled for i386 on amd64, you don’t need any libraries.

For cross-compiling, it doesn’t matter which pre-compiled packages you have installed (e.g. linux_amd64) because the .go source files are shipped, too. go build will just re-compile the libraries then:

$ echo $GOPATH
/usr/lib/gocode:/tmp/src/golang
$ GOARCH=386 CGO_ENABLED=0 PATH=~/go-i386/go/bin:$PATH go build -v
github.com/mstap/godebiancontrol
debtest
$ file debtest
debtest: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped

TODO

• In the long term, we should request a section “golang”, see http://bugs.debian.org/390609 for an example. This step should follow after there are a number of libraries.

Example binary + library packaging

debian/rules:

# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.

# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1

# GOPKG is the upstream path which you would normally “go get”.
# Using it allows us to build applications without patching locations.
GOPKG := code.google.com/p/codesearch

# Temporary working directory to which the source will be copied, then
# compiled.
TMPGOPATH = $(CURDIR)/debian/tmp/usr/lib/gocode

override_dh_auto_install:
        mkdir -p ${TMPGOPATH}/src/${GOPKG}
        # Copy all .go files to /usr/lib/gocode (we compile and ship).
        find . -path ./debian -prune -o -type f -name "*.go" -exec tar cf - {} + | (cd "${TMPGOPATH}/src/${GOPKG}" && tar xvf -)
        # Ensure that GOPATH is clean: It should only contain the temporary
        # /usr/src/golang containing the package we want to install and the
        # /usr/src/golang of the system we are building on. It should
        # specifically NOT contain the user’s local ~/gocode.
        GOPATH=${TMPGOPATH}:/usr/lib/gocode go install -v ${GOPKG}/...

%:
        dh $@ 

debian/codesearch.install:

debian/tmp/usr/lib/gocode/bin/* /usr/bin

debian/golang-codesearch.install:

usr/lib/gocode/src
usr/lib/gocode/pkg

For a binary-only package, use just the first .install file, for a library-only package, use just the second .install file.