Implement Go RFC0002: Decide Which Go Dependencies Will Be Paketo-hosted

[ryanmoran]

RFC

Summary

Remove the Paketo-hosted dependency.

The buildpack can use the dependency that is provided by Go which can be parsed from a JSON payload of thier download page with little to no modification. The precedence for this payload page existing can be found in the Go Docs for the website. The payload includes a SHA256 from Go meaning the artifact can be verified from the upstream. Here is a paketo-buildpacks/go-dist#442 showing the buildpack using the dependencies directly from the Go upstream. Because this dependency can be consumed from a trusted source, we should stop hosting it ourselves.

[jpena-r7]

Will the stacks be updated as part of this change since there will no longer be a paketo-specific dependency? I'm mainly wondering if support for all stacks can be added at the same time.

[fg-j]

@jpena-r7 That makes sense to me, since the upstream dependency is supposed to work for all linux consumers. Are you interested in multi-arch support as well? I'm not sure if we're well-positioned to enable that yet.

[jpena-r7]

Excellent!

There is interest in multi-arch support, but I suspect you would want to track that in a separate RFC. This fork is a first-pass at adding multi-arch support (and all stacks). We plan to propose changes to postal to support something like this universally.

[fg-j]

@paketo-buildpacks/go-maintainers is this done?

[ryanmoran]

@fg-j yep.