Comment # 7 on bug 1132101 from Aleksa Sarai

(In reply to Thorsten Kukuk from comment #6)
> (In reply to Jeff Kowalczyk from comment #5)
> go_nostrip: why do we need that? What's wrong with our default debuginfo
> packages? This only creates really fat binaries, and as result, I often see
> "-s -w" in go build arguments, which throws the debuginfo really away.

This is required because the default debuginfo stripping has caused several
cases in the past where Go binaries were subtly broken (in particular,
backtraces in panics were broken). I submitted patches to the post-build
scripts several years ago to fix it (currently strip(1) gives an error code,
but the file is still modified), but those patches weren't accepted.

Ideally, if everyone used the RPM macro for "go build", then we'd use '-s -w'
universally -- but as you said this means that debuginfo is completely useless.

> goprep: go mod init and go mod vendor is much more useful.

I can't disagree, though we don't have internet access in our builds so you
couldn't really do this in an OBS build.

> /usr/lib/rpm/golang.sh: this need a security review, fix filenames in /tmp
> written by root? Ouch. Same for the golang.req/golang.prov files.

Yeah, this should be reviewed. The current golang.sh is a bug-compatible
rewrite of the original which was written by the old Golang maintainer for
openSUSE. Personally I'm not really sold on golang-packaging at all (almost
nobody uses it, and those that do use it don't like it).