Hi all,

I've been thinking for some time now that it's important to define specific
roles in dependency management workflows. This is a needed task so that we
can start defining interoperability mechanisms between these roles.

I'm using the word "role" in my email here intentionally because we have
both package managers and build systems serving the same roles.

As to specifics, Daniel Ruoso and I are attempting to describe our current
model of dependency management workflows with three roles:


   - One is a dependency manager (a.k.a. package manager)
      - These resolve dependencies on source or binary artifacts
   - The second role is a build system
      - These construct and order build commands
   - The third role... needs name
      - Name suggestions would be helpful if any has some
      - This takes the universe populated by the dependency manager and
      flattens a projection into the specific view needed by the build
system to
      construct a target model (i.e., model libraries and executables)

Daniel has posted an illustrative diagram on roles and how they overlap on an
existing github issue <https://github.com/isocpp/pkg-fmt/issues/5>. Please
follow that link to see the annotated illustration of the concepts I'm
outlining here.

To the motivation for this discussion, this overlap is a root cause of
interoperability problems in C++ tooling. Because concerns mix, each
integration between pairings of build systems and package managers has to
be implemented and maintained individually. For instance, if a new build
system is introduced, manual engineering effort needs to be spent to get
that build system to work with each interesting package manager. This is an
O(m * n) problem where each unit is quite expensive on its own.

Instead, we need to define a clean "seam" between different tools so that
build systems and package managers can clearly understand what they should
*not* be responsible for. Instead, they should be able to target one
interoperation standard and support any number of integrations.

If we have time in the agenda for SG-15 in Tokyo this week, it would be a
good idea to discuss and get feedback on these ideas. In particular, this
shared understanding will support progress in the development of the Common
Packaging Standard (CPS) <https://github.com/cps-org/cps>.

Feedback here or in the above linked github issue would also be appreciated.

Thanks!
Bret