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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)