Fedora's golang is updated relatively frequently compared to RHEL, especially on the most currently supported version of Fedora, so I am more concerned about the policy for EPEL than for Fedora. One possible compromise would be to require this for Fedora but not for EPEL.

See my comments in https://bugzilla.redhat.com/show_bug.cgi?id=2376217#c24 (the part after "> I have not found this [...]"). There are other approaches available that are much better than bundling the entire Go toolchain in an individual package. This is against https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling, and the Go SIG does not support an exception.

@gotmax23 What approach is reasonable when one of the dependencies of the upstream go program requires a newer version of go than is available in RHEL and has an important security fix that impacts the go program? RHEL only updates go when go itself has an important security fix or when it's time to do an OS point release. That plus the fact that go minor versions are only supported one year means that there are often months that the current go version in RHEL is not supported by upstream go anymore. That causes many dependencies to require a newer version of go than is available in RHEL. The go toolchain has also begin more frequently updating the required version in go.mod by default so the problem is getting harder to manage, not easier.

I think this could fall under the exception in the bundling policy where it says "All packages whose upstreams have no mechanism to build against system libraries MAY opt to carry bundled libraries".

The source code for the go toolchain is small (30M) and can be built with a few lines of script in just a few minutes, so even though it seems ugly and SHOULD be avoided when practical, I don't think the policy should be that it MUST be avoided in all cases.

I listed three workable, Guidelines-adherent approaches in the package review to work around this problem:

You should consider other solutions before jumping to bundling the entire Go toolchain. If the version of Go in go.mod is too new, you can try patching it. https://github.com/openbao/openbao/blob/d7909766b2757ca04a5c622954bd70d4701ee469/go.mod#L3-L12 explicitly says that it can be disregarded. You could also file an issue to ask upstream to change this practice and leave the go value in go.mod set to the actual minimum supported version of Go. You can also consider building in legacy mode with Go modules disabled (export GO111MODULE=off) which is what %gobuild currently does by default (this will probably change eventually). This will make go just use any sources in the vendor directory and disregard any Go modules metadata [including any minimum Go version specified].

You could also backport the individual security patch if rebasing introduces Go version incompatibilities, Updates Policy violations, or other issues. If dependencies are the issue, Go Vendor Tools allows overriding versions of individual dependencies.

Also, the size of the Go toolchain isn't super relevant. The main issues here are that the Bundled Software Policy and the general Packaging Guidelines and standard practices are respected, making sure the distribution's compiler flags and patches are used, and not overriding major distribution components with bundled versions.

Ok you've convinced me.

This issue could be closed unless it is desired to make this more clear in the go packaging guidelines.