* Niall Douglas:

> Here's where a database of shared binary Modules changes things. Now
> zlib is a shared binary Module uploaded to a common package repository.
> All software consuming zlib uses it from the system Modules database (if
> the system Modules database is missing zlib, it is fetched). Each
> machine executes C++ programs from its system Modules database.
>
> zlib's authors fix a critical showstopper bug, and push the fix to the
> common package repository. The next time someone executes a piece of
> software using zlib, the new binary Module is used, rather than the old
> broken version. In one fell swoop, *all* software using zlib is fixed.
> No more waiting for maintainers to update each layer, until the fix
> percolates through to all use cases in production.

The flip side is that if this version of zlib is incompatible in some
way (not just in an API/ABI sense, but some application might assume
incorrectly that the compressed output never changes), then you can't
update zlib for those parts of the system that are exposed in a way
that increases risk, without also breaking those applications.

In general, existing module systems therefore do not automatically
upgrade to newer dependencies. If they support it all, the practice
is strongly discouraged. So in your zlib example, many applications
would still have to be updated to opt in to the newer zlib version.

I think the fundamental issue here is that updates to software
components are not free. For security updates, one culture has
evolved that favors minimal updates, essentially creating a version
that diverges from what everyone else runs. This sidesteps the issue
of API/ABI compatibility of updates. But even then, you still need to
do the upfront work to port everything to a single copy of zlib.
(zlib has some extremely reliable fingerprints you can use to find
extra copies, so it's not particularly difficult to deal with.)

But this is just a minority view. Many programmers really want to
avoid using system libraries such as zlib and bundle their own copies.
Maybe this practice would change if they could be certain that they
would get exactly the version they expect (without any random patches,
and thus without security fixes). But that conflicts with the goal of
applying bug fixes.