Go package guidelines

From ArchWiki

Revision as of 13:38, 19 December 2013 by Xyproto(talk | contribs)(Removed the section about packaging Go libraries. Go does not support dynamic libraries, so nobody are doing this (and it's not recommended by anyone).)

General guidelines

Naming

For applications written in Go, use the name of the application as the package name, in lowercase.

Be creative if the name is already taken.

For libraries written in Go, use go-modulename, in lowercase.

If the name already starts with go-, don't call the package go-go-modulename, but just go-modulename.

For PKGBUILDS that uses the "go" tool to download the package, only add "-git" to the package name if it's not built from a tarball or a from a tagged release (but from trunk/HEAD).

Similarly for mercurial packages, only add "-hg" to the package name if it's not a release-revision.

Extend this pattern for other version control systems.

The go tool has its own logic for which branch or tag it should use. See go get --help.

Consider adding the name of the author to the package name if there are several applications that are named the same, like dcpu16-kballardAUR.

In general, the most popular packages should be allowed to use the shortest or "best" name.

Postfixes to the package names (like -hg, -git or -svn) are optional if there are no official releases from the project in question. On one hand, it's common to use them when the package downloads from a VCS. On the other hand, most Go projects don't have any release-tarballs, only the repo which is used for branching/tagging the official release, if it's not trunk. Also, go get, which is the "official" way to install Go modules, uses the repositories directly. Use your better judgement.

Packaging

Go projects are either just library files, just executables or both. Choose the appropriate way of packaging them. There are several examples below.

Some Go applications or libraries have not been updated to the latest version of Go yet.

Running go build -fix may often work, but it may have to be fixed by the developer. Report an issue upstream if this is the case.

Several Go projects doesn't have a version number or a license file.

Use license=('unknown') and report an issue to the developer if a license file is missing.

Use version "0.1", "1" or the git-revision (or equivivalent for other version control systems) if the version number is missing.

Alternatively, use the current date as the version number, in this form YYYYMMDD.

Since Go applications are usually statically compiled, it's hard to envision reasons for packaging Go libraries instead of just Go applications.