It seems honestly odd to me not to just vendor what you need as standalone packages if your dependencies are that specific and you're a filesystem i.e. you use the bcachefs-errno package, not errno.
Debian tends to put their principles above pragmatism (for better or worse), so would they even agree with such vendoring when it's entirely meant as a way to bypass their vision/requirements/process for how dependencies should be handled?
That particular principle is bourne of pragmatism; Debian long ago learned the lesson that other distros are determined to relearn ( https://thenewstack.io/vendoring-why-you-still-have-overlook...) - vendoring is not good for security. In fact, I have come to view Debian's commitment to principles as almost always a practical matter, because those principles (almost?) always trade short-term pain for long-term quality and stability.
It's also effectively what the big cloud vendors do with their monorepos. This makes sense when you have upstreams which are slow at upgrading (e.g. it looks like Debian is upgrading packages packages using older bootstrap to bootstrap v5 across the board, and such fixes get pushed upstream; there's also tooling to watch new releases, so Debian's tooling effectively acts like a system-wide dependabot).
This isn't a Debian problem though, that's the point: if bcachefs-tools has such specific dependencies, then why doesn't it vendor it's own dependencies so it's clear they are packaged and used independently?
A bunch of the packages in the release at hand were actually upgraded, not downgraded, for example.
A counterargument would be that Rust+Cargo pins specific versions already. If you’re writing Rust, you should rarely need to vendor anything unless you’re maintaining a patched version or something.
Vendoring also bypasses the package cache and build cache. If 2 apps depend on foo-1.2.3, they can normally share the cached package and its build artifacts.
Basically, Cargo goes a long way toward ensuring you rarely need to bother with adding someone else’s code to your repo.
Oh, guess it does. I've been using sccache so long that I'd forgotten that.
Do you know off-hand why it doesn't, though? If 2 packages use foo 1.2 with the same features and, say, the default build settings, why not share them by default?
I think at the time Cargo was made it was just far simpler to implement. It's not just that, it's also rustc version, sometimes environment variables... much less likely to cause problems by keeping it per project. Of course that stuff still needs to be kept track of, but like, "to get a clean build, kill this directory" seems easier. Not sure if there is an explicit justification written down anywhere from 11 years ago.