RFC: Decouple Buildpack Plan and Bill-of-Materials #100
Conversation
Signed-off-by: Stephen Levine <stephen.levine@gmail.com>
…nstead of args Signed-off-by: Stephen Levine <stephen.levine@gmail.com>
|
@ekcasey changes made as suggested |
Signed-off-by: Stephen Levine <stephen.levine@gmail.com> Co-authored-by: Emily Casey <ecasey@vmware.com>
|
Final Comment Period with merge disposition, closing on 10 August, 2020. |
|
Would you mind clarifying the motivation behind this a bit more for me? Perhaps I don't understand the BOM usage as much as I thought I did, but why would you want to remove entries from it? Isn't it meant to provide an accurate assessment of everything that happened to the image? |
|
@dfreilich There's a difference between "what's in an image" and "what was contributed by a buildpack". In some cases these overlap (e.g. the BellSoft Liberica Buildpack contributes a version of Java) and in others they don't (e.g. the user's application has these dependencies at these versions). As it stands now, if a buildpack wants to contribute to the BOM, it direct effects the execution of later buildpacks via the build plan. In addition, if a buildpack wants to affect other the execution of later buildpacks, it must modify the BOM. So the goal of this RFC is to say, these two things are separate from one another and should be populated as such. |
Readable