Differences between revisions 34 and 35
Revision 34 as of 2013-06-30 18:42:25
Size: 2391
Editor: ?MichaelStapelberg
Comment:
Revision 35 as of 2013-08-27 19:35:56
Size: 2983
Editor: ?MichaelStapelberg
Comment:
Deletions are marked like this. Additions are marked like this.
Line 12: Line 12:
We use the -dev suffix to keep the namespace clean in case go supports shared libraries, which would then be shipped as golang-godebiancontrol. We use the -dev suffix to keep the namespace clean in case go supports shared libraries, which would then be shipped as golang-godebiancontrol.

In general, you should use the _import path_ for deriving a name, not the actual package name. Ideally, those are the same anyway. In case a package name already exists and you need a more specific one, add just enough qualifiers to make it more specific. As an example:

Assume code.google.com/p/go.net/websocket is uploaded as golang-websocket-dev, and you need to package github.com/stapelberg/websocket, then you would name the latter golang-stapelberg-websocket-dev. In case code.google.com/p/stapelberg/websocket pops up, that will be golang-codegooglecom-stapelberg-websocket-dev.

This page is about packaging golang libraries in Debian.

The one-sentence summary: use dh-golang, see bottom of the page.

Table of contents:

Package naming

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

We use the -dev suffix to keep the namespace clean in case go supports shared libraries, which would then be shipped as golang-godebiancontrol.

In general, you should use the _import path_ for deriving a name, not the actual package name. Ideally, those are the same anyway. In case a package name already exists and you need a more specific one, add just enough qualifiers to make it more specific. As an example:

Assume code.google.com/p/go.net/websocket is uploaded as golang-websocket-dev, and you need to package github.com/stapelberg/websocket, then you would name the latter golang-stapelberg-websocket-dev. In case code.google.com/p/stapelberg/websocket pops up, that will be golang-codegooglecom-stapelberg-websocket-dev.

Where to store go src/pkg data?

Go libraries (not binaries!) are present in Debian only for the purpose of building binary packages. They should not be used directly for Go development. Instead, the well-documented and platform independent way of using “go get” should be used.

Why should I use “go get” instead of apt-get to install Go libraries?

  • By using “go get” you are forced to set up the environment variable $GOPATH which you need for other “go” commands (e.g. “go build”, “go test”, etc.).
  • Debian packages install files to system locations, which users cannot modify. That means that users would not be able to upgrade packages with the canonical “go get -u <package>”. Even worse, when using sudo to forcibly modify the system files, it still would not work since no VCS information is contained in the Debian packages.

I want to build a Go binary Debian package

  • libraries are installed to /usr/share/gocode
  • When building Go Debian packages, GOPATH is set to “/usr/share/gocode”.

Multi-Arch/cross-compiling

Go libraries don’t ship any binary objects, only their source. The go compiler (>= 2:1.1-2) can cross-compile for all supported architectures.

TODO

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

  • lintian check for missing Built-Using

Example binary + library packaging

Use dh-golang, see http://anonscm.debian.org/gitweb/?p=collab-maint/dh-golang.git

It has an example/ directory with a control and rules file. In case you have any troubles with dh-golang, please contact stapelberg@

See http://anonscm.debian.org/gitweb/?p=collab-maint/golang-pq-dev.git for a library-only package (not using dh-golang (yet)).