I have been packaging Go programs and noticed that the executables remain `not stripped` after src_install. Found `RESTRICT+=" strip"` in go-module.eclass . Despite searching, I have not uncovered the rationale behind this restriction. However, based on my investigation, I propose that this restriction be reconsidered and potentially removed. ======BEGIN CLUES====== 1) Debian Go packages I have examined debian/rules for etcd-server, git-lfs, libpod, restic. None of them disable stripping. Notably, git-lfs previously included a dh_override_strip to disable stripping. But this is no longer the case, as evidenced by this commit: https://salsa.debian.org/go-team/packages/git-lfs/-/commit/7d8ec4e303ca9535c7e5a7479660a7f2856803ac . 2) Web search There are historical reports suggesting that stripping might break Go compiler. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717172 https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1200255 However, this seems outdated, as recent debian/rules only disable stripping for testdata. https://salsa.debian.org/go-team/compiler/golang/-/commit/4e9a859347c7d8e0ad860a6e4e390d132f178ea1 https://salsa.debian.org/go-team/compiler/golang/-/commit/5202f80135a371661199132170de3f3578591347 Further, dev-lang/go does not inherit go-module.eclass . There is a discussion thread talking about stripping. But provides no conclusive evidence that stripping issues persist. https://groups.google.com/g/golang-dev/c/ABppMOjYP6w 3) Gentoo Git History The RESTRICT=strip directive was part of the initial version of go-module.eclass, yet such a restriction does not appear in the earlier golang-build.eclass. ======END CLUES====== While I cannot definitively claim that stripping will never cause issues, there seems to be a lack of current evidence to support such concerns. Given the potential impact on numerous ebuilds from modifying the eclass file, I suggest introducing an eclass variable to allow for optional stripping. ```bash if [[ ! ${GO_ALLOW_STRIP} ]]; then RESTRICT=" +strip" fi ``` Based on further observation and feedback, we can remove it in future.
Not super familiar with Go and potential issues but I second this. It was the main reason I did not use go-module.eclass for x11-terms/kitty (a mixed Go, C, and python package) "for now". Lacked any way to override RESTRICT="strip" for non-Go bits (even dostrip did not work due to bug #697960), not to mention other defaults that assumed everything is Go (like QA_FLAGS_IGNORED='.*', albeit can override that one), and the unwanted dependency on unzip. Found out that it didn't even seem to matter if the Go-written tool is stripped as well so ultimately didn't restrict stripping for anything and haven't received bug report on that.
There used to be a very big warning in the past about stripping go binaries, but it looks like that may have changed. I'll take a look at dropping this. Thanks, William
