In almost every package management system I am used to, the dependencies are resolved.  The distinction is realized with transitive dependencies.  For example, in a C# project, I can require 2 libraries, and each of those libraries can in turn require the same logging API dependency.  The package management system figures out the version that satisfies the need for both transitive dependencies and either loads it at build time or sets up a dependency lock file for users to override if necessary.

Conversely, Helm embeds dependencies.  That means if my chart depends on another chart, that dependency is copied into my chart.  If I have two dependencies that in turn have the same dependency (like a configmap to hold a common logging configuration file) Helm will generate that transitive dependency multiple times.  Once for each dependency.  Obviously you can't have multiple configmaps with the same name.

I'm assuming the choice here was deliberate, but it is the choice that violates how I expect package management systems to behave the most.  So I find myself having to rethink everything.  Even OS level package managers like rpm and yum resolve dependencies at install time.  What is the rationale here?

--