> this is really about static vs dynamic linkage, regardless of the mechanism you use to effect run or build time binding of dependencies Are you familiar with

> this is really about static vs dynamic linkage, regardless of the mechanism you use to effect run or build time binding of dependencies Are you familiar with the functional package management approach of tools like Nix (https://nixos.org/nix/ https://nixos.org/nix/) and Guix (https://www.gnu.org/software/guix/ https://www.gnu.org/software/guix/)? They use dynamic linking but store all packages in a content-addressed format, outside the usual FHS. Packages are free to rely on separate versions of their dependencies as needed. Packages are defined in a 'source-based' format, but because of the content-addressable storage strategy, both Nix and Guix can offer transparent binary caching. Guix folks in particular are working on verifying the integrity of binary caches, so you don't have to blindly trust them, and they've developed a system they call 'grafting' which can safely and quickly replace vulnerable packages without recompiling. Both Nix and Guix have some container infrastructure as well. I'm not as familiar with the Guix side, but Nix has tooling for deterministically generating Docker images and systemd-nspawn containers, so you can leverage these packaging tools at the same time as existing container deployment infrastructure. I like your analysis of 'build time' vs 'runtime' integration of dependencies, and I think you might enjoy playing with/critiquing Nix and Guix, because they address these problems in a strange and powerful way. They use dynamic linking for deduplication and small upgrades, but try very hard to integrate everything they can at build time. I'd be interested to see where you think their approach is strong and weak, if you ever get a chance to try it out.