Date
1 - 3 of 3
Buildpack dependency on rootfs
Jack Cai
I notice that there are a few changes going into the rootfs [1]. Are there
corresponding changes in the buildpack which would make them unable to work properly in older levels of the rootfs (both cflinuxfs2 and lucid64)? I guess the larger question is that are we going to have hard dependencies from buildpack on the underlying stack levels? [1] https://github.com/cloudfoundry/stacks/commits/master |
|
Mike Dalessio
Hi Jack,
toggle quoted message
Show 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 https://github.com/cloudfoundry/stacks/commit/8770b5185656938c943ee9bb2a5892097d055264. 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 notice. 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[2] discusses the changes in each release. Hopefully this will increase transparency; please let me know if you have other ideas for communicating more clearly. [2]: https://github.com/cloudfoundry/stacks/releases Cheers, -mike 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 [1]. Are there |
|
Jack Cai
Hi Mike
toggle quoted message
Show quoted text
Thanks for addressing my questions gain. I agree that it's important to make both the rootfs and the buildpacks backward-compatible with each other. People often use master branch of the buildpacks to push applications on non-current levels of Cloud Foundry. The strategy you described will help such scenario. Jack On Mon, Aug 24, 2015 at 5:30 PM, Mike Dalessio <mdalessio(a)pivotal.io> wrote:
Hi Jack, |
|