On 2025-11-07 15:44:26 +0100 (+0100), Artem Goncharov wrote: [...]
When 2 different projects depend on a single library (i.e. libssl) of different versions you should not have a bigger problem when updating this lib, since Rust project is compiled with hopefully a certain supported version. From what I read about the debian Rust packaging process is that it is expected to have crates in many different versions available as packages exactly to address that. You, as a user, will not have a broken runtime system just because dependency was updated for the other project. From my point of view the constraints issue in runtime is addressed with that. Am I wrong here? [...]
The challenge they have with that is security support. If 10 different packaged applications all require different versions of the same dependency and there is a security vulnerability impacting all versions of that dependency, the security team needs to backport 10 different versions of the fix in one release of the distribution alone (then multiply that by the number of distribution releases they may be supporting at the same time). As a result, there is significant pressure within distributions to prefer carrying as few versions of a library in each release as possible, ideally just one. This problem is not unique to the Rust ecosystem though, and is one of the main reasons for distributions to simply not package otherwise popular applications written in Go or JavaScript too. What you view as a run-time "dependency hell" is often the preferable tradeoff to build-time "security hell." -- Jeremy Stanley