Bug#1062016: Consider providing separate librsvg2 package

[Fabian Grünbichler]

On Wed, 31 Jan 2024 00:14:50 +0100 Matthias Geiger <werdahias at 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.