On Wed, 31 Jan 2024 00:14:50 +0100 Matthias Geiger <werdah...@riseup.net> wrote: > please consider providing a librust-librsvg2-dev package. This should > just install the rust source files under > /usr/share/cargo/registry/librsvg2-VERSION. This will be needed by > loupe/glycin to load svgs (other crates also started depend on > librsvg2). > > f_g: Is an install of those files compatible with our setup even if some > deps of librsvg2 are not in debian yet (it's built vendored) ?
Hi (f_g here ;)), For librsvg to be usable as a Rust dependency in Debian, all its dependencies (which are currently vendored) also need to be packaged as Rust source code in a way that allows rdeps of librust-librsvg-dev to find them. There are two approaches for the vendored deps: 1) package each of them in the regular fashion (if missing, upgrading/.. otherwise), and build-depend on them in src:librsvg instead of vendoring them 2) ship them in some non-standard path (from the vendored copies), but make cargo pick them up via some hack (patch/source replacement, path deps, extra vendoring step in d/rules of all rdeps, ..) Building a librust-librsvg-dev containing the librsvg Rust source (and for variant 2 above, the vendored sources) should be fairly straight-forward. Obviously 1) is the cleaner approach, since it would also allow src:libsrvg to stop vendoring its Rust dependencies, reducing the number of duplicate copies in the archive. I am not sure what sort of exception/agreement there is in place w.r.t. librsvg's current vendoring, and whether that should be re-evaluated now that it is properly published on crates.io and no longer uses vendoring upstream (AFAICT). The main downside is that currently non-vendored statically linked Rust binaries/cdylibs only have "limited" security support. IMHO this is something we should try to solve during the Trixie release cycle, or at least start working on in earnest.
