Stack Removal Planning

[sophiewigmore]

The CNB Project is getting closer to delivering stack and mixin removal (buildpacks/spec#336), their progress towards delivery can be tracked in this issue.

As a project, we should consider what we will need to do in order to adopt stack removal, as this will have an impact on buildpacks across the board. We can use this post as a general discussion and planning area until we are ready to create issues to implement the work. As we look into this track of work further, we will keep this post up-to-date. Anyone in the community should feel free to chime in with thoughts they have in this regard!

[BarDweller]

Quick brain dump of places I've spotted stack usage so far in Paketo...

• builder.toml defines stack id, referenced by buildpack.toml today.
  • stacks are replaced by 'target data', and buildpack.toml can include references to targets
• stack id used by some buildpacks to filter dependencies by stack id (eg node-engine)
• stack id (previously) used by some buildpacks to gate running of the buildpack at all (many of these today are now stacks id="*")
• jam uses its own file 'stack.toml' to define build/run images with stack id
  • jam also has a 1:1 concept of builder to run image that was previously true for a stack, can now be 1:n
• pipeline-builder also understands stack today for a few things.

[dmikusa]

In the Java buildpacks, I believe we switched everything to stack = "*", at least for dependency and buildpack compatibility. My understanding is that we can just add the target sections and it's compatible, actually encouraged, to have both.

Moving forward it's encouraged for buildpack authors to support both [[stacks]] and [[targets]] sections in buildpack.toml for maximum compatibility.

I think we'll also likely just set the os/arch, because none of our dependencies really care about the distribution/distro version.

+1 We'll definitely need to update pipeline-builder/CI to support targets too.

---

Aside from that, there are a couple of places where we check the stack because there are differences in the package set with the stacks and we need to handle something differently because a package is not present in the tiny stack, for example (it's almost always bash/a shell that causes the difference).

I believe we can use the CNB_TARGET_* to handle this. My understanding is that these env variables will be present and we can look at them to determine behavior like this. All of the present stacks are Linux AMD64 Ubuntu Jammy, so I think we'll also need to coordinate the IDs we use for CNB_TARGET_ID so that we can differentiate between full, base, tiny, and static.

[hone]

@dmikusa does relying on CNB_TARGET_ID for package info, tightly couple the buildpacks to the underlying base image?

[dmikusa]

Yes, it has come up as an issue but only infrequently. Very seldom, someone is using a different/custom stack, and looking at the stack name fails because they are just using a different/custom stack. I suspect the same thing would come up here.

I think we'd talked about trying to use some sort of way to detect if the required dependency is present, but it gets really complicated. The buildpack could do that at build time but not at runtime, at least not until after a container has been created and then it's really too late.

It would be nice, but I'm not sure how else we could go about checking if certain requirements are present like bash or a particular glibc version or something like that.

[natalieparellano]

Cross posting for visibility: buildpacks/community#230