Optional provides in the build plan

[loewenstein]

Hi all,

I have been wondering for a while, if the relatively strict provisions when it comes to mismatches of provided dependencies that are not required is causing more harm then good.

• If a required buildpack provides a dependency that is not required by the same buildpack or a subsequent buildpack, the trial MUST fail to detect.
• If an optional buildpack provides a dependency that is not required by the same buildpack or a subsequent buildpack, the optional buildpack MUST be excluded from the build phase and its requires and provides MUST be excluded from the Build Plan.
• If an extension provides a dependency that is not required by a subsequent buildpack, the extension MUST be excluded from the build phase and its provides MUST be excluded from the Build Plan.

This forces optional dependencies to be separated into individual buildpacks or extensions. Wouldn't an alternative where the lifecycle just purges unmatched provides from the build plan and buildpacks and extensions are mandated to only install dependencies that are in the purged build plans be easier to reason about and more versatile?

The concrete example I have in mind would be a set of minimal run image and matching extension¹ and language specific packaging buildpack. The extension could provide all kinds of OS-level dependencies and the buildpack could require all kinds of OS-level dependencies based on language specific package information (potentially manually maintained²). A concrete example would be the psycopg package that lists libpq.so as a prerequisite at runtime.
As the specification is written, this would require an individual extension per potential dependency, which can become quite a lot and likely also be pretty expensive during build time with all the Dockerfiles being created an processed via kaniko.

Let me hear your thoughts, would that be useful?

Best regards
Jan

Footnotes

1. Aligned with run image in terms of package manager being used, e.g. dpkg / apt-get or apt or rpm. ↩

2. Often only provided as part of the package documentation, hence it needed to be formalised outside the package manager metadata. ↩