In general, this is for legacy reasons only. There was a point where not all lifecycle versions understood the wildcard stack option. Having both allowed the buildpacks to work on a broader set of versions. The image-labels buildpack is a good example.

We're probably past the point where we need them, so if you're submitting a PR, you could remove that bit or if you're creating a new buildpack you probably don't need anything beyond the wildcard stack.

As a side note, not all buildpacks will be compatible with all stacks. If the buildpack is installing dependencies, you need to be careful to make sure that the dependencies you're installing can work on any stack.

Dan

On 1/6/23 16:37, Michael Dawson wrote:

This may be a naive question but I see a number of the build packs (for example https://github.com/paketo-buildpacks/image-labels/blob/main/buildpack.toml) include both a 

[[stacks]
  id = "*"

entry as well as some additional more specific ones.  

Since I think that entry would allow any stack to be used with the build pack, what is the purpose of also having the more specific entries ?

I'm asking to better understand if the extra entries signal that there is something I might need/be able to do in order to support a new stack (even optionally)