Well, there is nothing that says you can't have proper dependency tracking just because something is statically linked. Didn't say so. It is just easier with d

Well, there is nothing that says you can't have proper dependency tracking just because something is statically linked. Didn't say so. It is just easier with dynamic linking, because you can see what libraries (and versions) a binary is linked against. But can be built, now that more and more languages have access to language package managers with proper dependency tracking. Actually, approaches such as Nix' buildRustCrate (where every transitive crate dependency is represented as as a Nix derivation) + declarative package management offer this today. But with curl | bash or traditional package managers, which are most widely used today, this is kind of dependency tracking hard/ad-hoc. But can be built, now that more and more languages have access to language package managers with proper dependency tracking. But then a static C library is used and nobody knows where it came from. Even if you look at the Rust ecosystem, which generally does things well when it comes to dependency handling, crates are all over the place when it comes to native libraries. I have seen everything from crates that use a system library (or something discoverable via pkg-config), via crates that have the library sources as a git submodule and build them as part of the build-script, to crates that download precompiled library from some shared Dropbox link. Another fun example from another language ecosystem. numpy uses OpenBLAS. They compile their binary wheels on CI. However, OpenBLAS itself is retrieved as a precompiled binary from another project [1]. However, the rabbit hole goes deeper. In case OpenBLAS is built for macOS, a precompiled disk image is retrieved from yet another repository [2]. This disk image is added to that repository, but comes from yet another place. This is all sort of the opposite the lessons to take from Reflections on Trusting Trust and the bootstrapping that the Guix folks try to do. Anyway, with the mindset that most developers have, we will never have proper dependency tracking. [1] https://github.com/MacPython/openblas-libs https://github.com/MacPython/openblas-libs [2] https://github.com/MacPython/gfortran-install/tree/d430fe6e38b6c5149c53f775a4437964e2f7b883 https://github.com/MacPython/gfortran-install/tree/d430fe6e3... [3] http://coudert.name/software/gfortran-4.9.0-Mavericks.dmg http://coudert.name/software/gfortran-4.9.0-Mavericks.dmg.