I know this isn't your fault, but... There are a few of us who don't want gigabytes of insecure rust code statically linked into libraries on our systems that handle untrusted input. And on the arches with no rust, we're already forcing people to use an old version of librsvg with known vulnerabilities because gtk+ depends on it. Could you hide the librsvg dependency behind a new USE=svg flag (default enabled, if you want), so that we're able to choose security if we care more about that than SVG icons?
I really don't know.
I don't see GTK+ linking with librsvg. I guess I'm curious if things still work, what doesn't work, etc, without librsvg.
Given adwaita-icon-theme depends on librsvg it'd still be needed indirectly either way, unless gtk+ can be made note to depend on that but I recall it wasn't that simple.
(In reply to Ionen Wolkens from comment #3) > Given adwaita-icon-theme depends on librsvg it'd still be needed indirectly > either way, unless gtk+ can be made note to depend on that but I recall it > wasn't that simple. Hm. That dependency is supposedly for the benefit of /usr/bin/gtk-encode-symbolic-svg, which belongs to gtk+. I would think that it's taken care of by the dependency in gtk+. That binary doesn't link with librsvg, so it's probably using rsvg-convert under the hood. That's at least a little promising, since (long-term) I can write a wrapper that fakes the rsvg-convert interface and calls inkscape instead.
Ok, I went ahead and tried it: 1. Re-emerged everything with USE="-svg" 2. Added librsvg to package.provided 3. Rebuilt everything that has a dependency on librsvg 4. Rebooted There are two main problems. First, the adwaita-icon-theme will fail to install, because its configure.ac checks for /usr/bin/gtk-encode-symbolic-svg, and when that executable exists, the build system expects it to work. This was fixable by marking gtk-encode-symbolic-svg non-executable so that the configure.ac check misses it. (It should probably be removed from the install image with USE="-svg"). Second, your icons get a little messed up. The default adwaita sort of works, but random icons are missing here and there. Switching to the high constrast icon theme fixes most of those issues, though, leaving only a few rare "icon not found" where I think someone has naively hard-coded an icon name. Having to use the high contrast icons sucks, but not more than having to deal with rust.
(In reply to Michael Orlitzky from comment #4) > > That binary doesn't link with librsvg, so it's probably using rsvg-convert > under the hood. That's at least a little promising, since (long-term) I can > write a wrapper that fakes the rsvg-convert interface and calls inkscape > instead. I was looking in the wrong place. That executable is just a little wrapper around gdk-pixbuf, and while gdk-pixbuf doesn't link to librsvg, the librsvg package installs $(libdir)/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so to allow SVGs to be loaded into pixbufs. So to work around this in the long run we'd need some other SVG pixbuf loader.
This is indeed a WONTFIX as far as I'm concerned, at least as long as we don't have any alternative gdk-pixbuf loaders to provide for SVG handling. Many desktop apps icons would just be broken without one.
(In reply to Mart Raudsepp from comment #7) > This is indeed a WONTFIX as far as I'm concerned, at least as long as we > don't have any alternative gdk-pixbuf loaders to provide for SVG handling. > Many desktop apps icons would just be broken without one. Regardless of the ugly user experience, on hppa, ppc, sparc, alpha, ia64, mips, and s390, that will eventually be the only way to install gtk+ unless something is done about librsvg. Pretending that the old librsvg-2.40.21 is safe because nobody else uses it can only work for so long =)
ppc, sparc, mips and s390x are supported by rust, it is a gentoo problem that we don't have it there. Maybe dropping gtk support will have someone interested show up and deal with rust there. I have no issues with just dropping gtk support completely for alpha, hppa and ia64 at some point of time, or making the icons broken by not having the PDEP just for them or something.
Ok, I'll just deal with it myself for now. To anyone else interested, the process was pretty easy: 1. Check your USE=svg dependencies. Some of them can use inkscape or ksvgtopng instead of rsvg-convert, and may be able to use e.g. cairosvg in the future. Disable USE=svg for anything else. 2. Uninstall any package that unconditionally needs the library. GIMP, for example, will fail to build because they dropped the option to disable SVG import. 3. Uninstall librsvg and add it to package.provided. 4. chmod -x /usr/bin/gtk-encode-symbolic-svg to fix the adwaita-icons build. 5. Switch to the high contrast icon theme, or some other icon set that provides PNGs for most things.
(In reply to Michael Orlitzky from comment #10) > > 4. chmod -x /usr/bin/gtk-encode-symbolic-svg to fix the adwaita-icons build. > > 5. Switch to the high contrast icon theme, or some other icon set that > provides PNGs for most things. Update for posterity: Instead of settling for half-broken icons, you can grab the prebuilt icon package from Andreas's binhost: https://dilfridge.blogspot.com/2021/09/experimental-binary-gentoo-package.html There's no real benefit to building the icons from source anyway, and none of my problems with rust persist in the resulting PNGs.
*** Bug 911533 has been marked as a duplicate of this bug. ***
