All, First off, everything I'm saying here is definitely open to discussion; they are issues I have found with go 1.13.
with Go 1.13, go modules are the default way to build software written in Go. If upstream has a go.mod file in their distribution, this version of Go will assume that they are using modules unless modules are disabled explicitly by setting the GO111MODULE environment variable to off[1], so if your upstream does not have go.mod, it will work as before. This is not turned off globally because upstream is encouraging projects to move to using modules [3] [4]. So far, here is what I've found if an upstream uses go modules. dev-vcs/hub vendors the modules into their upstream repository using "go mod vendor" and keeps go.mod and go.sum up to date. The build commands in their makefiles use the "-mod vendor" switch as well. In this case, the ebuild author doesn't have to do anything about the modules. If the modules are not vendored (there is no vendor directory in the upstream repository), the only option I've tried so far is to run "go mod vendor" in the root of the upstream repository then tar up the vendor directory and mirror it on our infrastructure. In that scenario, you need to add "-mod vendor" to any "go build" commands upstream uses and have a src_prepare function that moves the vendor directory into the appropriate place. See www-apps/trickster (not trickster-bin). This also seems to avoid the module mirror database. There is another option I want to try which is adding "go mod vendor" to src_unpack for go packages. Thoughts? Thanks, William [1] https://golang.org/cmd/go/#hdr-Module_support [2] https://golang.org/doc/go1.13#modules [3] https://blog.golang.org/migrating-to-go-modules [4] https://blog.golang.org/using-go-modules
signature.asc
Description: Digital signature
