[bug#51845] [PATCH 0/2] Add librsvg-bootstrap

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi,

Am Sonntag, den 14.11.2021, 20:07 +0200 schrieb Efraim Flashner:
> > As a temporary resolution to the rebuild issue, we could pin the
> > dependencies of librsvg to some specific versions and only bump 
> > them something awful happens.  I'm not sure whether librsvg
> > exposes any of the Rust nastiness to its dependencies, ideally
> > hoping that it would not.
> 
> I don't believe librsvg exposes any rust-y stuff.
That sounds like a good start for once.

> > WDYT?
> 
> (ins)efraim@3900XT /tmp/librsvg-2.50.7$ ls vendor/ | wc -l
> 226
> 
> There are 226 crates that upstream bundles with their source. I
> suppose we could pare it down to about 200 by careful pruning but
> it's part of librsvg and not going away.
Well, I'd suggest snippeting them away, but that's a different topic.

> (ins)efraim@3900XT ~/workspace/guix-core-updates$ git grep \,librsvg
> | wc -l
> 103
I'd hazard a guess that most if not all of these 103 packages are
themselves gtk-adjacent, so what really is the issue we're solving
here?  What is the point of maintaining an extra version for 101 of
them when a potentially vulnerable GTK sits right next to them?

> I'm suggesting that for gtk+@2 and gtk+@3 we use the bundled crates
> and for the other 101 packages we continue to use our current
> version, where we replace all of the bundled crates with our own
> copies, which get updated more often than librsvg does.
> 
> With our current rust tooling I don't think it'd be that easy to find
> the ~226 crates that librsvg depends on, and it wouldn't be great to
> lock them due to librsvg being an input for gtk2/3.
Said input exists due to gdk-pixbuf+svg, with the +svg part being
largely optional – the most common failure mode of it not being
included are broken button textures, which we could fix by pre-
rendering images with a suitable tool, such as inkscape.  We could
easily do a minimal gtk[+]? without it.

As for the lock, why can't we?  gtk+ is already core-updates material,
so it stands to reason that anything causing it to rebuild is too. 
Rather than push down blobs to the users because we can't deal with
Rust, we should fix Rust or make it go away from the build.

WDYT?