Get Gentoo!
Development Guide
  1. Master Index
  2. Eclass Reference

go-module.eclass

Name

go-module.eclass -- basic eclass for building software written as go modules

Description

This eclass provides basic settings and functions needed by all software written in the go programming language that uses modules. If the software you are packaging has a file named go.mod in its top level directory, it uses modules.

Modules have been the preferred method of tracking dependencies in software written in Go since version 1.16, so if the software isn't using modules, it should be updated.

Also, if the top level go.mod file contains a go directive that specifies a version of go prior to 1.14, this should be reported upstream and updated.

If the software has a directory named vendor in its top level directory, the only thing you need to do is inherit the eclass. If it doesn't, you need to also create a dependency tarball and host it somewhere, for example in your dev space. It's recommended that a format supporting parallel decompression is used and developers should use higher levels of compression like -9 for xz.

Here is an example of how to create a dependency tarball. The base directory in the GOMODCACHE setting must be go-mod in order to match the settings in this eclass.

$ cd /path/to/project
$ GOMODCACHE="${PWD}"/go-mod go mod download -modcacherw
$ XZ_OPT='-T0 -9' tar -acf project-1.0-deps.tar.xz go-mod

Since Go programs are statically linked, it is important that your ebuild's LICENSE= setting includes the licenses of all statically linked dependencies. So please make sure it is accurate. You can use a utility like dev-go/golicense (network connectivity is required) to extract this information from the compiled binary.

Supported EAPIs

7 8

Example 

inherit go-module

SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz -> ${P}.tar.gz"
# Add this line if you have a dependency tarball.
SRC_URI+=" ${P}-deps.tar.xz"

Exported Phases

  • src_unpack

Functions

ego [<args>...]

Call go, passing the supplied arguments. This function dies if go fails. It also supports being called via nonfatal. If you need to call go directly in your ebuilds, this is the way it should be done.

go-module_set_globals

Convert the information in EGO_SUM for other usage in the ebuild.

  • Populates EGO_SUM_SRC_URI that can be added to SRC_URI

  • Exports _GOMODULE_GOSUM_REVERSE_MAP which provides reverse mapping from distfile back to the relative part of SRC_URI, as needed for GOPROXY=file:///...

go-module_setup_proxy

If your ebuild redefines src_unpack and uses EGO_SUM you need to call this function in src_unpack. It sets up the go module proxy in the appropriate location.

go-module_src_unpack

If EGO_SUM is set, unpack the base tarball(s) and set up the local go proxy. Also warn that this usage is deprecated.

  • Otherwise, if EGO_VENDOR is set, bail out.

  • Otherwise do a normal unpack.

_go-module_src_unpack_gosum

Populate a GOPROXY directory hierarchy with distfiles from EGO_SUM and unpack the base distfiles.

Exports GOPROXY environment variable so that Go calls will source the directory correctly.

_go-module_gosum_synthesize_files

Given a path & version, populate all Goproxy metadata files which aren't needed to be downloaded directly.

  • .../@v/${version}.info

  • .../@v/list

_go-module_src_unpack_verify_gosum

Validate the Go modules declared by EGO_SUM are sufficient to cover building the package, without actually building it yet.

go-module_live_vendor

This function is used in live ebuilds to vendor the dependencies when upstream doesn't vendor them.

_go-module_gomod_encode

Encode the name(path) of a Golang module in the format expected by Goproxy.

Upper letters are replaced by their lowercase version with a ! prefix.

Variables

EGO_SUM

This is replaced by a dependency tarball, see above for how to create one.

This array is based on the contents of the go.sum file from the top level directory of the software you are packaging. Each entry must be quoted and contain the first two fields of a line from go.sum.

You can use some combination of sed/awk/cut to extract the contents of EGO_SUM or use the dev-go/get-ego-vendor tool.

One manual way to do this is the following:

cat go.sum | cut -d" " -f1,2 | awk '{print "\t\"" $0 "\""}'

The format of go.sum is described upstream here: https://go.dev/ref/mod#go-sum-files

For inclusion in EGO_SUM, the h1: value and other future extensions SHOULD be omitted at this time. The EGO_SUM parser will accept them for ease of ebuild creation.

h1:<hash> is the Hash1 structure used by upstream Go The Hash1 is MORE stable than Gentoo distfile hashing, and upstream warns that it's conceptually possible for the Hash1 value to remain stable while the upstream zipfiles change. Here are examples that do NOT change the h1: hash, but do change a regular checksum over all bytes of the file:

  • Differing mtimes within zipfile

  • Differing filename ordering with the zipfile

  • Differing zipfile compression parameters

  • Differing zipfile extra fields

For Gentoo usage, the authors of this eclass feel that the h1: hash should NOT be included in the EGO_SUM at this time in order to reduce size of the ebuilds. This position will be reconsidered in future when a Go module distfile collision comes to light, where the Hash1 value of two distfiles is the same, but checksums over the file as a byte stream consider the files to be different.

This decision does NOT weaken Go module security, as Go will verify the go.sum copy of the Hash1 values during building of the package.

_GOMODULE_GOPROXY_BASEURI

Golang module proxy service to fetch module files from. Note that the module proxy generally verifies modules via the Hash1 code.

Users in China may find some mirrors in the default list blocked, and should explicitly set an entry in /etc/portage/mirrors for goproxy to https://goproxy.cn/ or another mirror that is not blocked in China. See https://arslan.io/2019/08/02/why-you-should-use-a-go-module-proxy/ for further details

This variable is NOT intended for user-level configuration of mirrors, but rather to cover go modules that might exist only on specific Goproxy servers for non-technical reasons.

This variable should NOT be present in user-level configuration e.g. /etc/portage/make.conf, as it will violate metadata immutability!

I am considering removing this and just hard coding mirror://goproxy below, so please do not rely on it.

_GOMODULE_GOSUM_REVERSE_MAP

Mapping back from Gentoo distfile name to upstream distfile path. Associative array to avoid O(N*M) performance when populating the GOPROXY directory structure.

GO_OPTIONAL (SET BEFORE INHERIT)

If set to a non-null value before inherit, the Go part of the ebuild will be considered optional. No dependencies will be added and no phase functions will be exported. You will need to set BDEPEND and call go-module_src_unpack in your ebuild.

Authors

William Hubbs <williamh@gentoo.org>

Robin H. Johnson <robbat2@gentoo.org>

Maintainers

William Hubbs <williamh@gentoo.org>

Reporting Bugs

Please report bugs via https://bugs.gentoo.org/