In D12424#190106, @Alphare wrote:

Unfortunately, zstd > 0.5.3 does not support our minimum version of Rust which is 1.48.0. I'd already tried updating, but this'll have to wait until Debian stable updates (or someone adds back backwards compat, which I doubt).

I'm curious about this. This is a compiled language - you have to ensure that you can *run* on a debian stable machine, but I don't see a strong reason to require that you can *build* on a debian stable machine? Especially since rust lets you have user-directory installations of rustc? The only reason to require this is if you expect that debian stable will take a new version of hg, which seems unlikely (they'll backport any fixes, but won't just willy nilly upgrade hg from 5.6.1 to 6.1 or 6.2 for any reason). So I think you shouldn't hold back to require debian stable can build the package, though it should be able to build on whatever rust comes with debian testing, for obvious reasons. This appears to currently be 1.57.

In D12424#191195, @spectral wrote:

I'm curious about this. This is a compiled language - you have to ensure that you can *run* on a debian stable machine, but I don't see a strong reason to require that you can *build* on a debian stable machine?

The point of this (very annoying, I admit) limitation to Debian Stable *is* to allow its users to build a more recent Mercurial while trusting the toolchain of their distro, i.e. without relying on rustup and other prebuilt binaries. A CI runner is also a good example of such a "user".

Whether we choose to purposely break that workflow because we want a more recent compiler is up for debate, I think we can afford to stay behind to ease compatibility. Lastly, we may have downstream crates in the future, like the planned hgignore crate could be used by ripgrep and the like and we would need to be pretty backwards compatible for this.

I think it is pretty ridiculous that Linux distributions artificially constrain the forward progress of entire language ecosystems by moving at a glacial pace. Python version compatibility is already problematic for Mercurial and now we're throwing Rust into the mix. And that is arguably worse since Python does major releases once per year versus Rust's 6 week release cadence.

Given that Rust is an optional dependency for Mercurial, I'd like to think there is some room to consider more aggressively upgrading the minimal supported Rust version. If enough projects start doing this, I suspect the distros will eventually realize their current practices aren't in the best interests of their end-users and they'll come around to supporting more modern Rust so they can package the applications their users demand.

I don't want to block this too much if I'm about the only one who cares enough about this. I don't like raising the minimum version of anything without a good reason because it breaks lots of things (including compatibility with downstream crates, not just with distros), but not being able to upgrade our own dependencies might be good reason enough. It's kind of a vicious circle, but I get it.

I will send an email to the packaging mailing list to ask them what a change in policy (to say, move to the Debian testing version) would change for them if anything, and make our decision from there even if it may go against their wishes.