To some extent, I see that more as "Distros have ossified around the workflows and tooling that is essentially 'a third-party package manager like Conan for C++, but for C'".
How do you deal with vendored single-header libraries and bespoke implementations brought about by C's lack of a cross-distro, cross-platform dependency handling story? You generally don't.
As that article points out, Rust's approach to package management allows things to be shared between projects which, in practice, don't get shared between C projects.
With Crates.io not allowing existing crate versions to have their contents modified and Cargo.lock providing a SHA256-verified record of the exact dependencies your project used, you've got a record of what build dependency versions went into your package, which can be used by tools like `cargo audit`.
Yes, it means that you need tooling to automate rebuilding the binaries whenever they're statically linked but, as Michał Górny pointed out in 2012, that's already necessary with libraries that use C++ templates and, as was said in "Let's Be Real About Dependencies", "On the flip side, I wonder how many times vlc’s XML parser has been fuzzed?"
While it's slow going, discussion and an experimental prototype do exist for embedding full dependency versioning information inside Rust binaries to further help that approach: https://github.com/rust-lang/rfcs/pull/2801
To some extent, I see that more as "Distros have ossified around the workflows and tooling that is essentially 'a third-party package manager like Conan for C++, but for C'".
How do you deal with the same monomorphization problems in C++ libraries? See https://blogs.gentoo.org/mgorny/2012/08/20/the-impact-of-cxx...
How do you deal with vendored single-header libraries and bespoke implementations brought about by C's lack of a cross-distro, cross-platform dependency handling story? You generally don't.
https://wiki.alopex.li/LetsBeRealAboutDependencies#gotta-go-...
As that article points out, Rust's approach to package management allows things to be shared between projects which, in practice, don't get shared between C projects.
With Crates.io not allowing existing crate versions to have their contents modified and Cargo.lock providing a SHA256-verified record of the exact dependencies your project used, you've got a record of what build dependency versions went into your package, which can be used by tools like `cargo audit`.
Yes, it means that you need tooling to automate rebuilding the binaries whenever they're statically linked but, as Michał Górny pointed out in 2012, that's already necessary with libraries that use C++ templates and, as was said in "Let's Be Real About Dependencies", "On the flip side, I wonder how many times vlc’s XML parser has been fuzzed?"
While it's slow going, discussion and an experimental prototype do exist for embedding full dependency versioning information inside Rust binaries to further help that approach: https://github.com/rust-lang/rfcs/pull/2801