See: https://forums.gentoo.org/viewtopic-t-1164351.html Gtk3 always depends on librsvg, which is quite heavy by itself, but librsvg also needs rust, which is a huge package. Combined, these dependencies take over 15 times longer to build than gtk(on my system). To me, this seems unneeded and bloated. Maybe a USE flag can be added for librsvg. I'll also mention the fact that gtk+ is always build with lpr support, regardless of USE flags. Is this intended? If so, why is it like this? The gains are not that big, only 2 files no longer compiled. Still, why build them if they are not needed? See: https://forums.gentoo.org/viewtopic-t-1164350.html
lpr is a single C file for an extra print backend with zero extra dependencies, so it is just matching what `-Dprint_backends=auto` would do without cups present. Almost any GTK app will need a SVG gdk-pixbuf loader to show their icon, or at least app icon, and we aren't really in the business of breaking apps nor forcing 99% of the gtk depending packages to additionally depend on librsvg themselves to not have broken app icon, or 75% of the apps to not have icons (don't quote me on the percentages though). It is quite hard for individual app maintainers to figure out whether they need such a dep on the app or not. I do not see us revisiting this until there is no viable alternative gdk-pixbuf SVG loader. Marking this one as duplicate of the bug that had more discussion on this. *** This bug has been marked as a duplicate of bug 788016 ***
The problem is that the dependencies are many times heavier than the dependent package. If I were to build it, it would take even longer to build that palemoon, which is the main reason I use gtk. It wouldn't that big of a problem if librsvg was written in something like C, but I am looking at almost an hour of unneeded build time. From my understanding, the way qt handles this is that it only builds dev-qt/qtsvg if there is actual need for it, and not just as an unconditional dependency. That seems like a better way to handle this, as the build time involved is significant.
There is almost always an actual need for it on a given users system and we don't have the mechanisms to make sure that all the gtk using packages have an extra librsvg dependency to ensure things work. QtSvg is a specific API that you link to and make use of manually in the code, whereas with GTK it's a case of a pixbuf loader - you give it a path to an image file and if it happens to be SVG, you need a SVG pixbuf loader to handle it, and librsvg is the only one that provides one. Disclaimer: I am not very familiar with Qt or QtSvg, and there might be such implicit aspects going on as well on top of the explicit linkage use cases (like in GNOME world some apps link to librsvg directly as well and use its API directly)
I meant that we don't have mechanisms to ensure packages that ACTUALLY do load SVG icons would have a librsvg dep, in addition to gtk dep, when they merely load a SVG icon resource or file and display it via generic API that the app doesn't need to link librsvg for and we won't find it in meson.build dependency lists, etc. This is many packages, see e.g. /usr/share/icons/hicolor/scalable/apps/ They might also use SVG variants of standard icons (the other stuff in /usr/share/icons/hicolor/scalable folders).
I'm still using the hack from bug 788016 on my laptop, but it's not a great experience, so I would recommend it only to my most stubborn friends. The main problem, still, is SVG icon support. Everything expects to be able to load an SVG into a GdkPixbuf, and librsvg is what provides the pixbuf loader for the SVG format. Entire applications will be devoid of icons without it. That's _relatively_ good news, because a pixbuf loader probably isn't that hard to write, if you already have a decent SVG library. But of course there are no decent SVG libraries right now that do not share the same dependency problem. Since the last time I looked, svgpp made a release, and libmsvg was born, but neither look like they have a ton of momentum. Anyway, if you really want this fixed, that's the path to success in my opinion. The SVG library doesn't have to be bullet-proof, it just has to make icons. You need only have enough faith in it to waste a few days figuring out how to write the pixbuf loader.
(In reply to Michael Orlitzky from comment #5) > I'm still using the hack from bug 788016 on my laptop, but it's not a great > experience, so I would recommend it only to my most stubborn friends. > > The main problem, still, is SVG icon support. Everything expects to be able > to load an SVG into a GdkPixbuf, and librsvg is what provides the pixbuf > loader for the SVG format. Entire applications will be devoid of icons > without it. > > That's _relatively_ good news, because a pixbuf loader probably isn't that > hard to write, if you already have a decent SVG library. But of course there > are no decent SVG libraries right now that do not share the same dependency > problem. Since the last time I looked, svgpp made a release, and libmsvg was > born, but neither look like they have a ton of momentum. > > Anyway, if you really want this fixed, that's the path to success in my > opinion. The SVG library doesn't have to be bullet-proof, it just has to > make icons. You need only have enough faith in it to waste a few days > figuring out how to write the pixbuf loader. I have this in my package.provided: $ tail -5 /etc/portage/profile/package.provided | head -3 # gtk+:3::gentoo without bloat gnome-base/librsvg-2.56.2 x11-themes/adwaita-icon-theme-44.0 I have not noticed any problems with it. I am using dwm though, so no tray icons and such. I have used palemoon, firefox-bin and librewolf like this(though librewolf needs rust so no big gains there). Everything works the same for me. There is also a patched ebuild in perfect gentleman's overlay: https://gitlab.com/Perfect_Gentleman/PG_Overlay. No need to have rust for gtk+.
(In reply to Mart Raudsepp from comment #1) > lpr is a single C file for an extra print backend with zero extra > dependencies, so it is just matching what `-Dprint_backends=auto` would do > without cups present. Any reason to keep it that way? Also, lpr is enabled even with cups present: -Dprint_backends=cups,file,lpr
There is no reason to change it, either. Someone might be using lpr in theory, it doesn't cost us anything more than a single tiny C file compilation.
I think GTK is gradually moving away from gdk-pixbuf loaders itself as well. The bad news for you is that this would then be using the relevant library themselves directly (they already use libpng and libjpeg-turbo directly iirc in gtk4, so if they have a need to do SVG directly, it'd be hard dep on librsvg at that point probably). They do this because the gdk-pixbuf loaders are very primitive in todays world - they don't do colorspace handling, 10-bit, HDR, and so on, for which GTK now handles it itself to be in more control and able to do such stuff, as libpng/libjpeg-turbo and so on do provide the support. I haven't heard anything for SVGs in this area yet though.
