> Apt’s dynamic library mechanism is designed around C’s dynamic library support. This doesn’t work with many other languages. It certainly doesn’t work with ru

> Apt’s dynamic library mechanism is designed around C’s dynamic library support. This doesn’t work with many other languages. It certainly doesn’t work with rust, which doesn’t have an ABI. Nothing's stopping them from shipping them as static libraries - with some simple tooling it's easy enough to figure out what needs rebuilds and automate it. > There are too many rust packages, and they update too frequently for apt to keep up. And what do you think cargo does to keep up? It uses a metadata system and a common build system across packages to make automatic discovery of dependency trees seamless. There's nothing stopping a debian maintainer from writing automatic tooling around this, in fact, it already exists[1]. > A dpkg wouldn’t even work on every version of Debian. And neither does cargo as soon as there's a crate that requires a too new version of openssl or whatever other C library. The reality of the matter is that cargo can't express the full dependency tree including any cross-language or system-level dependencies. > We have a similar problem with ruby gems, nodejs packages (in npm), etc etc. I can name a few problems that make nodejs slightly different, and it's the fact that npm doesn't deal with source packages the way cargo does, it deals with binary packages that can include whatever flavor of bundled shared libraries du jour, probably only built for x86_64 and if you're lucky arm64, and with unclear source and/or build instructions or OS compatibility. Its build system also has support for defining custom build procedures and calling random binaries during build like the npm package for 7zip, which is also prebuilt. This, and the tendency to make microdependencies just doesn't mesh well with distributions that need to make sure everything has corresponding source and can be built reproducibly. Ruby gems have been solved since they've been around for longer, as have python packages, even though the latter keeps introducing wrenches to make packaging harder. > Cargo, npm, and friends run rings around apt from the point of view of developer mindshare, ease of use, platform independent packaging, and so on. Maybe, but they introduce their fair share of problems as well. I've already mentioned the piss poor support for cross-language dependencies, but let's mention that the "stores" the packages for these are published to are only moderated after the fact - it's really easy to introduce malware into these stores without anyone noticing, and it's happened a bunch of times. Distributions make sure the binaries correspond to the sources[2], and the maintainers are the first to spot any obvious malware or breakage in software as a result of a change. Sometimes it goes under their noses as well[3], but these cases are much more rare than npm breakage. In general, the distribution model allows for better trust and security, and I think this is something that should be valued more than it currently is. [1]: https://salsa.debian.org/rust-team/debcargo/ https://salsa.debian.org/rust-team/debcargo/ [2]: https://reproducible-builds.org/ https://reproducible-builds.org/ [3]: https://www.theregister.com/2015/06/17/debian_chromium_hubbub/ https://www.theregister.com/2015/06/17/debian_chromium_hubbu...