Bug#1017906: Bug#1017892, #1017906: vendored stuff in librsvg

[Simon McVittie]

Control: severity 1017892 wishlist
Control: severity 1017906 serious

On Sun, 01 Jan 2023 at 17:15:19 +0100, Paul Gevers wrote:
> On Mon, 22 Aug 2022 14:29:56 -0700 Sean Whitton <spwhitton at spwhitton.name>
> wrote:
> > #1017892 is wishlist or not a bug. [...]
> 
> > #1017906 *might* be a problem. [...]
> 
> It seems like you mixed up the bugs in your control message?

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