http://bugzilla.suse.com/show_bug.cgi?id=1132101
http://bugzilla.suse.com/show_bug.cgi?id=1132101#c7
Aleksa Sarai
(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). -- You are receiving this mail because: You are on the CC list for the bug.