It is still under construction and content may change. Do not rely on the information on this page.
Go Packaging Guidelines
Naming
Package Names
TODO: write this section. Intent is that libraries are named like golang-googlecode-net
Versions
Many Go libraries do not use package versions or have regular releases, and are instead maintained in public version control. In this case, follow the standard Fedora version conventions. This means that often Go packages will have a version number of "0" and a release number like "0.10.git27435c6".
Packaging Binaries
Some applications (like Docker) simply happen to be written in Go and are not meant to be developed against (they do not offer a Go language API). These should be named after the upstream project, and do not need a "golang" prefix or an import path added to the name.
The debuginfo mechanism in RPM does not currently work with Go binaries; until that is fixed, strip Go binaries manually.
Packaging Libraries
Go libraries packaged in Fedora are primarily for the purpose of building Fedora binary RPMs, and not meant to be developed against otherwise -- for that, we encourage the upstream "go get" idiom and a per-user $GOPATH.
The standard golang compiler only produces static libraries. There is little value in shipping these prebuilt, especially since these libraries are very specifically tied to the exact minor release of the golang compiler. Instead, each library package should consist of a -devel subpackage which installs .go source code to /usr/share/gocode/src, under the appropriate import path.
Binary packages which build against this source will set $GOPATH to /usr/share/gocode.
Security in Go Language Packages
If there is a security issue in the standard Go library or in a library built into binary Go programs, all affected RPMs will need to be rebuilt..
Thanks
These guidelines are Fedora-specific but are intended to match Debian practice where that is reasonable.
Discussion
See Talk:PackagingDrafts/Go for discussion.