Hi,

See the discussion on the Debian Rust maintainers list for background:
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022857.html

For more details how to solve this in a way that makes ftp-masters happy,
please refer to them.


The vendor subdirectory in the librsvg source package contains copies of
various Rust libraries in specific versions. Some of them are packaged in
Debian (i.e. the version from Debian should be used), others contain
autogenerated files for which the original source is not in Debian.

Examples for this are

  - vendor/semver corresponds to the rust-semver package in Debian. Here
    version 1.0.10 is included while Debian currently only has version 1.0.4.
    Both versions should be API compatible so that's not necessarily a
    problem for switching to the Debian version.

  - vendor/memchr corresponds to the rust-memchr package in Debian. Currently
    these two have the same version.

  - vendor/png corresponds to the rust-png package in Debian. Here version
    0.17.5 is included while Debian currently only has version 0.16.8. Both
    versions are not API compatible.

  - vendor/glib-sys corresponds to the rust-glib-sys package in Debian. Here
    version 0.15.10 is included while Debian currently only has version
    0.14.0. Both versions are not API compatible at all.

    In addition the src/lib.rs in that subdirectory has exactly the same
    problem mentioned in the above discussion. It is autogenerated from
    GLib-2.0.gir by the gir tool, and GLib-2.0.gir is autogenerated from the
    GLib (glib2.0 source package) source code.

    Either the original source in the exact version used here and everything
    to generate the files has to be shipped with the source package, or the
    files have to be regenerated at build time with whatever is available in
    Debian.

    See the above discussion for more details.


These are not all files affected. You'll have to check the whole content of
the vendor subdirectory on every release and ideally make sure each of these
are packaged in Debian in the correct version.

Control: clone -1 -2
Control: retitle -1 librsvg: Has vendored copies of Rust libraries that are in Debian
Control: retitle -2 librsvg: Contains generated files whose source is not necessarily the same version that's in main
Control: tags -1 + help
Control: tags -2 + help

This seems like two separate issues, so I'm cloning it.

Is there ftp team consensus that either or both of these issues are RC?

Regardless of whether they are RC, the GNOME team is unlikely to be
able to solve these without help. In particular, I have been one of
the more frequent uploaders of librsvg in recent years, not because
I *want* to be involved with librsvg, but because *someone* has to do
it (as a dependency of GTK 4 and GNOME, among others). I don't know
Rust or the Rust toolchain, so I am not well-placed to make extensive
structural changes.

The Rust tooling in Debian seems to have a general assumption that
every Rust library is built using Cargo as its top-level build system and
packaged individually (no vendoring). Conversely, because it was gradually
ported from C to Rust, librsvg is built using Autotools (invoking Cargo
internally); and its dependencies are provided as vendored modules. I do
not have sufficient Rust knowledge to fit Debian's Cargo wrappers into
this Autotools build, I certainly do not have sufficient Rust knowledge
to adapt it to be able to cope with having half the dependencies vendored
and the other half coming from external packages, and I am definitely
not the right person to be packaging all the vendored dependencies as
individual Rust libraries.

I already dread having to package a new upstream version of librsvg,
because it means losing several hours of my life to checking a diff and
updating d/copyright. I had been forcing myself to do this work anyway,
because part of being involved in a volunteer project is having to do work
that we don't want to do, but perhaps I should have been refusing to touch
this particular package and letting its occasional CVEs and other RC bugs
go unfixed until someone with the right skillset picked it up? I've done
my best, but I know my best is not good enough. Other Debian contributors
with more time and/or expertise are welcome to step in any time.

If Debian as a project requires librsvg to be maintained in particular
ways, then someone who is capable of doing that work will need to do it,
and I'm sorry but that's not me.

    smcv

control: severity 1017906 wishlist

Hello,

#1017892 is wishlist or not a bug.  Certainly not a DFSG issue.

#1017906 *might* be a problem.  If there is generated Rust code without
the source code used to generate it, or the tool used to transform the
sources into the generated Rust code, then there is source code missing.
I have not looked into the package to see whether this is actually the
case.

Hi Sean,

It seems like you mixed up the bugs in your control message? I'm
currently staring at #1017892 (vendored copies) because it's RC, but I
agree with you it looks much less severe. Given that, do you think
#1017906 (no source) should be raised again until somebody has figured
out if there's *no* RC problem?

Paul

Control: severity 1017892 wishlist
Control: severity 1017906 serious

I'm not Sean, but I agree the one that is *maybe* RC is #1017906
(depending on how the ftp team choose to interpret the source code
requirement, corresponding source, and similar things), while #1017892
(use of vendored Rust at versions chosen by upstream) is not.

If the ftp team consider #1017906 to be RC, then the solution to it is
to bundle another copy of GLib source code with librsvg, corresponding
to the version of GLib's GObject-Introspection data in vendor/glib-sys,
similar to what I did for src:gobject-introspection (I used 3.0 (quilt)
multiple original tarballs, which seemed slightly nicer than dropping it
into debian/ and having it duplicated in every Debian revision). Using
the GIR XML generated by Debian's GLib is not a solution, because that
would result in glib-sys changing its API whenever it was rebuilt with
a newer (or older!) GLib, and rebuilt libraries changing their APIs is
generally bad news.

I personally think GIR XML is a reasonable form for modification and
a plausible way to exercise freedom-to-modify, despite not being the
"least-derived" source, but it is true that it was mechanically generated
from GLib's C code and is not the form you would modify to make an
upstream contribution (the upstream of vendor/glib-sys is unlikely
to accept any contribution to the GIR XML not of the form "update to
GLib x.y.z", but the DFSG does not require that changes made downstream
could be accepted upstream, and if it did then we would immediately lose
sqlite and some GNU projects).

As a result, I personally think this is not a particularly productive
use of Debian maintainers' time; but if it's a requirement then I'll try
to make time for it at some point, at the cost of an equivalent amount
of other Debian work not getting done.

    smcv