Why use RPMs (distribution packages in general) at all ?!
Distribution RPMs enables you to get signed curated content, with security updates, bug fixes, general updates, some level of testing, and known ways of reproducing the build locally. Of course, it has its cost mostly in the package size overhead and packaging infrastructure overhead (yum, dnf, apt....).
Why package and use distribution (Fedora) packages?
This helps to manage a stable subset of the go world. As many upstreams do not provide release nor API stability. In the current situation, package rebase and API stability is driven by consuming the project in a de-bundling effort lead by Jan Chaloupka and his tooling project Gofed which is still in "draft state", Fedora golang packaging guidelines. This should lead to better possibilities for security bug fixes and assessment of the impact of those, as common vendoring/bundling and static linking in Go makes it really hard track this down. So there are still no general API guarantees apart of the base standard library.
What is different in Fedora's golang?
Fortunately, nothing is removed anymore. Before there was patch removing elliptic curve p224 while awaiting review of its fitness from Fedora Legal team. The review concluded last year and nowadays nothing is missing from Fedora's golang in any supported release. Also, there are few additional bits. First, since there is the possibility of go1.8 to override default crash traceback level to "crash" level at build time, using build tag "rpm_crashtraceback" and in older versions of golang not supported by upstream and still supported in Fedora, there are backports of security fixes.
How to install Fedora golang?
To install golang just use "dnf install golang", this will install the golang compiler (aka GC), a basic set of sub-packages, golang package with files like VERSION, API files,...a golang-src package with source files, excluding test sources and golang-bin containing compiler and basic tools binaries. To get complete upstream like a tree you need two additional sub-packages, golang-tests containing all standard tests and golang-misc. containing entirely upstream misc. directory (including more tests among other things).
There hasn't been any mention of two sub-packages, golang-race containing prebuilt std lib with race detector enabled (available only on x86_64/amd64 platform, since go1.8) and golang-shared containing prebuilt standard library in form of dynamically linkable object file.
All of this lives in the GOROOT directory, which is located under /usr/lib/golang/ on all architectures. The standard GOPATH for distribution packages, which is not set in the environment by default, is /usr/share/gocode. This is where you will find the source code for all non-standard library packages provided by the distribution (mostly in *-devel sub-packages).
Workspace setup
For your own Go workspace, you should use your own path or, since Go1.8, the implicit ~/go directory. Of course, you can use the distribution path, but in that case, it will be much harder if you decide to develop against libraries provided by the distribution or get projects that are already provided in distribution and installed locally. The best solution, in this case, is to have to have your own workspace and possibly use distribution libraries by setting multiple directories in the GOPATH env variable like "GOPATH=/my/go/path:/usr/share/gocode". This will cause other packages to be "go get" into the first directory, but all listed directories will be searched for build dependencies.
With this you should be set for your go project development, just go get it or start it from scratch.
As a developer, you can get a no-cost Red Hat Enterprise Linux Developer Suite subscription, which includes Red Hat Enterprise Linux 7 server, a collection of development tools, and much more.
Last updated: March 20, 2023