Dear backports ftpmasters, the question how to (potentially) handle Rust crate backporting for Trixie came up in the Debian Rust team recently, and we would like to have your input!
some background information that might be relevant: - Rust executables need to be statically linked - there is no stable ABI for linking - as a result, Rust "library" packages actually contain source code - Rust dependency trees are (quite a bit) larger then C/.. ones in practice this means that for backporting an application (or shared library for consumption via a C-compatible interface) there are two options: A) backport everything first backport all the `librust-XXX-dev` dependencies making up the transitive dependency tree, then backport the application/library itself. this potentially means backporting hundreds of packages to backport a single "leaf" package. backporting multiple packages with overlapping dependency trees at different points in time might lead to conflicts - although that might be overcome by versioning the libraries and tightening dependencies, increasing the backporting-delta. B) vendoring vendor all those dependencies into the applicate/libary package, only backport this special variant of the package which would then be self-contained. this is obviously a deviation from the usual packaging practices in Debian. some packages already use this approach in sid/testing/stable (for various reasons), e.g. the Rust toolchain, the browser packages, librsvg all vendor all their Rust dependencies inside their respective source package. obviously both approaches have significant downsides, and there also is the option of not backporting anything at all, or limiting backporting to A) and only allowing packages that don't require huge amounts of library backports. thanks for reading, Fabian
