-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement Go RFC0002: Decide Which Go Dependencies Will Be Paketo-hosted #666
Comments
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. |
@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. |
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. |
@paketo-buildpacks/go-maintainers is this done? |
@fg-j yep. |
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.
The text was updated successfully, but these errors were encountered: