Re: Buildpack dependency on rootfs
Hi Jack,toggle quoted messageShow quoted text
Thanks for asking these questions. Not knowing what specific changes you're
referring to, I'll try to address some different aspects of the topic.
First, just to set expectations, `lucid64` is no longer supported, and so
new buildpacks do not officially support it. This was pretty well announced
and discussed on the old vcap-dev mailing list, as well as the current
cf-dev mailing list. We do have tools and artifacts to generate buildpack
binaries for unsupported rootfses, though -- notably
https://github.com/cloudfoundry/binary-builder. Please let me know if you
need assistance in using any of the buildpacks tooling to do nonstandard
things, I'm happy to work with you on it.
At some point, it's *possible* that a buildpack will be released that won't
work on an older version of cflinuxfs2. Just as an example, we're thinking
about removing the vendored version of jq from the go-buildpack, and
relying on the version of jq put into the rootfs in
However, we'd only do something like that after asking for comments and
communicating clearly on the mailing list as well as in the release notes.
Generally speaking, the goal is to provide a rootfs that's
backwards-compatible with buildpacks (e.g., we don't remove packages over
time, we only add or update packages); and to provide buildpacks that are
backwards-compatible with rootfses. It's obviously possible that we'll
break this contract, but we'd only do so after a comment period and lots of
Have I answered your questions?
It might be worth noting that we only recently started to track the rootfs
as a versioned artifact; the GitHub release history discusses the
changes in each release. Hopefully this will increase transparency; please
let me know if you have other ideas for communicating more clearly.
On Mon, Aug 24, 2015 at 5:06 PM, Jack Cai <greensight(a)gmail.com> wrote:
I notice that there are a few changes going into the rootfs . Are there