"Dr. Tobias Quathamer" <[email protected]> writes: > Maybe you're even better off by using Mathias' advice and set the > GODEBUG variable in d/rules. That is at least an official way to > influence the build, while DEB_GOMINCOMPAT is only available in Debian > and is intended to be short-lived.
Thanks for this pointer -- Mathias' suggestion wasn't to set GODEBUG directly but to patch upstream source code. What is prefered here? I've been setting the GODEBUG environment variable when invoking dh_auto_test for golang-* libraries: https://salsa.debian.org/go-team/packages/golang-github-ysmood-got/-/blob/debian/sid/debian/rules?ref_type=heads That approach requires that all other packages using this library replicate that setting, which was a pain. Would you recommend setting GODEBUG during dh_auto_test only? Or during dh_auto_build when building binary packages? Would you use the environment variable or patching source code like Mathias did? I'm not entirely confident about the differences between 1) Setting DEB_GOMINCOMPAT in debian/rules. 2) Patching *.go files with go:debug statements. 3) Setting GODEBUG environment variable during dh_auto_test. 4) Setting GODEBUG environment variable during dh_auto_build of binaries. 5) Some long-term solution to not do GO111MODULES=off. In an ideal case they would all result in the same outcome, I think. But I'm worried about non-ideal cases, which could be the majority right now. It seems that 1) has some chance of fixing more things in resulting binaries that could be lost when doing 2)-4), and 2)-4) could even be hiding the problem so it is harder to discover. /Simon [1] https://salsa.debian.org/go-team/packages/incus/-/commit/0710b22ddd38f9deec41e98c9aca9fd7c8c5d3aa
signature.asc
Description: PGP signature
