Bug 1914743

Hello, do you have example of what you are doing and trying to achieve? So we can better understand your situation. Something like a spec of your package or copr repository with your package.

Part of my .spec file:

```
%build
export GOPATH=/usr/share/gocode:$(pwd)/ideco:$(pwd)/thirdparty
export GOBUILDFLAGS="%gobuildflags"
GOBUILDFLAGS=${GOBUILDFLAGS/ -a /}
export CGO_ENABLED=0 # makes binaries smaller and static
eval "go build $GOBUILDFLAGS ./ideco-acl-helpers/..."

%install
export GOPATH=/usr/share/gocode:$(pwd)/ideco
export GOBUILDFLAGS="%gobuildflags"
GOBUILDFLAGS=${GOBUILDFLAGS/ -a /}
export CGO_ENABLED=0
export GOBIN=%{buildroot}%{_bindir}
eval "go install $GOBUILDFLAGS ./ideco-acl-helpers/..."

%check
export GOPATH=/usr/share/gocode:$(pwd)/ideco:$(pwd)/thirdparty
export GOBUILDFLAGS="%gobuildflags"
GOBUILDFLAGS=${GOBUILDFLAGS/ -a /}
export CGO_ENABLED=0
eval "go test $GOBUILDFLAGS ./ideco-acl-helpers/... ./ideco/..."

```

I have a project that compiles to multiple binaries in /usr/bin. In order not to build every binary separately, I decide to use `go install`.


Structure of my project:

./ideco-acl-helpers
./ideco-acl-helpers/cmd
./ideco-acl-helpers/cmd/acl-authorized
./ideco-acl-helpers/cmd/acl-authorized/main.go
./ideco-acl-helpers/cmd/acl-check-cn
./ideco-acl-helpers/cmd/acl-check-cn/main.go
./ideco-acl-helpers/cmd/acl-check-cn/main_test.go
./ideco-acl-helpers/cmd/acl-check-sni
./ideco-acl-helpers/cmd/acl-check-sni/main.go
.....
./ideco
./ideco/src
./ideco/src/ideco_acl_helpers
./ideco/src/ideco_acl_helpers/content_filter
./ideco/src/ideco_acl_helpers/content_filter/aliases.go
.....
./ideco/src/ideco_acl_helpers/logging
./ideco/src/ideco_acl_helpers/logging/logger.go
.....

I think that this is not accounted, covered by current Fedora packaging approach in general not only in Go. In %build you are supposed to produce all the binary artifacts in the "work directory" and in %install place them in the final destinations in the file tree. Go's install is just fancy build and unfortunately have some more side effects(gopath,caches,...) than (/usr/bin/)install command. So I think that using go install(building) in install section is not correct(at least from the point it is not accounted for in current design of Go packaging) or possibly even something that we don't want to be done at all.
Maybe Nicolas/nim can add more, if my understanding is incorrect in some ways.

To note 
export CGO_ENABLED=0 # makes binaries smaller and static
it is not generally true, that it will produce static binaries(in C sense), it will just prevent usage of C and might break builds in certain scenarios.

As a side note to #3 you can try something like this to build all of your binaries:


for d in $(go list ./... | grep -v cmd); do
    go build ${d}
done

1. OKAY. Even %gobuild actually spoils home directory with temporary files.
2. CGO_ENABLED - is just for my case. It's possibly not OK in general. Let's not discuss that in this issue.
3. Yes, I can use some loop to build all the binaries, but build process will be significantly slower if I use recommended (!) %gobuild macro. Because my binaries have many "shared" sources and "-a" will force to re-compile the shared sources every time %gobuild is called.

I don't see any profit in "-a" flag. Why not to remove it ? For what purpose it was added ? What are the cases when re-compile is every required ? GO caches intermediate results in some structure like CCACHE, so I don't know cases where force recompile could be useful.

so what ?

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.