@buildpacks/platform-maintainers what are our thoughts on continuing to support Ubuntu 16.04 releases?

The question is what our support requirements are, and how much we want to go past them. It's hard to say, if we don't have metrics on usage, and don't know what will happen.

I would rather not set up our own instance on Equinix - we already have trouble with the Windows runners, and adding a standalone one just for packaging seems suspect.

If those are the only two options, then I would vote for removing xenial support, unless we get pushback from the community (according to https://wiki.ubuntu.com/Releases, while it isn't EOL, it is at the end of standard support, and as an open source community, I don't feel like we are obligated to provide full support until EOL unless our community shows that it's invested in helping us do that).

The question is whether there's another option. It is go, so we definitely shouldn't need to build it on xenial to create a compatible binary; do we need a xenial machine to push the ppa? Can we do it otherwise? And overall, I wonder whether we should consider moving to a tool like goreleaser to manage our pretty complicated release process/matrix.

The question is whether there's another option.

I did bring this up on another similar request.

maybe there's a way to improve our workflow to better support many more possible releases.

Maybe we can use docker images to produce and publish the PPAs. We already do this for testing our PPA installation so I can't foresee any challenges.

do we need a xenial machine to push the ppa?

IIRC the answer is yes for our current method.

I wonder whether we should consider moving to a tool like goreleaser.

Don't have a lot of knowledge there but if it's possible, I would definitely be in favor of it.

Unfortunately, it seems like we won't be able to get the xenial delivery pipeline back up for this release (0.27.0).

There are a lot of brought on complications due to BurntSushi/toml bringing in io/fs and embed. Even though they are gated via //go:build go1.16 and // +build go1.16 they are not ignored by go mod vendor which we use here.

A few attempts that failed:

1. go build without vendoring
   • Yields: build github.com/buildpacks/pack/cmd/pack: cannot load io/fs: malformed module path "io/fs": missing dot in first path element
2. Running go mod vendor on go1.16 then go build on go1.13
   • Yields: build io/fs: cannot load io/fs: open /pack/vendor/io/fs: no such file or directory

Thanks for doing the legwork on this! Why does this only happen for xenial? And is there a fix we can do for the future?

Sadly, this was closed preemptively.

Why does this only happen for xenial?

This happens because xenial does not have a golang package in the "backports" PPA we are using for anything higher than 1.13. See this page for packages available.

By comparison, you can see that our other targeted distributions do. For example, bionic.

Is there a fix we can do for the future?

The way that we implemented the original pipeline is depending on the backport golang PPA to set the required dependencies in our package. We can try a few avenues to remove the dependency on the backport golang PPA.

A few untested options that come to mind are:

1. Expect users to have go (1.16) installed.
   • Reasoning: Most of the linux instructions for installing go suggest doing it manually such as the official docs.
   • Drawback: The UX would suffer because it's no longer a single command to install pack and it's dependencies.
2. Ship pack as a precompiled binary.
   • Reasoning: Go has the ability to compile to a portable binary.
     • In our case, this is true because we don't use CGO.
   • Drawback: We would need to create a package per architecture.
   • Drawback: I can't find any concrete references but my mind tells me that this is frowned upon in the Linux community.

We haven't delivered a xenial artifact for a while and nobody is complaining about it, our current workflow delivers PPA for bionic, focal, jammy and lunar (see here) and xenial is too old!

I am going to close this one