Backporting Rust applications for Trixie
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
Reply to: