Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 547710 - x11-libs/gdk-pixbuf not pulling in gnome-base/librsvg
Summary: x11-libs/gdk-pixbuf not pulling in gnome-base/librsvg
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] GNOME (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-25 14:46 UTC by haarp
Modified: 2015-04-26 05:14 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description haarp 2015-04-25 14:46:44 UTC
Applications based on gtk2 and gdk-pixbuf need librsvg to display SVG images. However, that dependency is missing and doesn't even exist as an useflag

games-emulation/pcsx2 from the vortex overlay is such an application. It's also 32-bit-only. If the user's icon theme contains SVG icons, pcsx2 requires librsvg[abi_x86_32] to display these.

However, since gdk-pixbuf is not pulling in librsvg, librsvg[abi_x86_32] is never installed.

pcsx2 could explicitely depend on librsvg, but that didn't seem like the proper solution. An svg useflag on gdk-pixbuf sounds like a much cleaner solution.

See also: https://github.com/nE0sIghT/vortex-overlay/issues/6
Comment 1 Mart Raudsepp gentoo-dev 2015-04-25 15:40:33 UTC
imho such themes should RDEPEND on it then, if they need the librsvg provided theme engine to display its images. I believe it's also a USE dep on librsvg to provide said theme engine, and I'm not even sure it exists in latest librsvg anymore
Comment 2 Alexandre Rostovtsev (RETIRED) gentoo-dev 2015-04-25 16:09:24 UTC
(In reply to haarp from comment #0)
> pcsx2 could explicitely depend on librsvg, but that didn't seem like the
> proper solution.

But that is the proper solution.

If you package requires a specific plugin for gdk-pixbuf, it needs to depend on  the package providing the plugin (e.g. librsvg), not only on gdk-pixbuf.

What you are proposing - for a core driver library to optionally pull in other packages providing plugins for itself - is a rather bizarre pattern, and I can't think of any examples in the main portage tree which work this way. After all, you don't expect e.g. dev-lang/python to pull in modules from dev-python/*, for for media-libs/gstreamer to pull in plugins from media-plugins/gst-*

The closest analogy would be meta packages (e.g. gst-plugins-meta) that pull in a collection of plugins together with the main library. But for gdk-pixbuf + librsvg that seems like overkill.
Comment 3 Alexandre Rostovtsev (RETIRED) gentoo-dev 2015-04-25 16:25:04 UTC
Oh, and after reading your bug report on nE0sIghT - this is a bug in your custom theme's ebuild, you forgot to add gnome-base/librsvg[${MULTILIB_USEDEP}] to its RDEPEND.
Comment 4 nE0sIghT 2015-04-25 16:29:58 UTC
(In reply to Alexandre Rostovtsev from comment #3)
> Oh, and after reading your bug report on nE0sIghT - this is a bug in your
> custom theme's ebuild, you forgot to add
> gnome-base/librsvg[${MULTILIB_USEDEP}] to its RDEPEND.

The problem is that such themes can be installed by user in home folder, so there is no ebuild at all.

There was similar bug reports:
https://bugs.gentoo.org/show_bug.cgi?id=373001
https://bugs.gentoo.org/show_bug.cgi?id=363715

And svg use flag was added early, but dropped for some reason
Comment 5 haarp 2015-04-25 16:33:08 UTC
(In reply to Alexandre Rostovtsev from comment #3)
> Oh, and after reading your bug report on nE0sIghT - this is a bug in your
> custom theme's ebuild, you forgot to add
> gnome-base/librsvg[${MULTILIB_USEDEP}] to its RDEPEND.

The theme in question is locally installed in the user's home.

But let's assume it was an ebuild. Then your suggestion is confusing me. Are we expecting themes to explicitely install with abi_x86_32 now, so that they can pass that ABI down to librsvg? Even Adwaita, Gnome's premier icon theme, depends on librsvg, but has no way of depending on librsvg[abi_x86_32].
Comment 6 Alexandre Rostovtsev (RETIRED) gentoo-dev 2015-04-25 16:48:58 UTC
Hmm, interesting point. Then maybe we want gtk+ to rdepend on librsvg[${MULTILIB_USEDEP}] (since it's gtk+ that is loading custom themes).
Comment 7 nE0sIghT 2015-04-25 16:57:09 UTC
librsvg installs loader (plugin?) for gdk-pixbuf. I think gdk-pixbuf must pdepend on librsvg with use svg as it was early.

equery f librsvg | grep pixb
/usr/lib64/gdk-pixbuf-2.0
/usr/lib64/gdk-pixbuf-2.0/2.10.0
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders
/usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so
Comment 8 Alexandre Rostovtsev (RETIRED) gentoo-dev 2015-04-25 18:55:38 UTC
After discussion on IRC: a basic icon theme is a collection of images and should be independent of toolkit. Forcing every theme's ebuild to carry multilib dependency logic for gtk, and for qt, and for ... gets unsustainable. (The fact that the gnome team got deps wrong for our own adwaita theme is an indication of the problem with this approach!) Instead, it would be better if a basic icon theme (png/jpg/svg icons) can reasonably expect that any toolkit with a default set of flags is able to load it; custom dependencies in themes should only be needed for themes that do something unusual or that are not toolkit-independent.

I still don't like gdk-pixbuf pulling in its own plugin.

But gtk+ seems an appropriate place for the dependency: if it's responsible for loading themes, it ought to pull in librsvg to load a basic icon theme correctly.

+  25 Apr 2015; Alexandre Rostovtsev <tetromino@gentoo.org> gtk+-2.24.27.ebuild,
+  gtk+-2.24.27-r1.ebuild, gtk+-3.14.9.ebuild, gtk+-3.14.10.ebuild:
+  Add librsvg[${MULTILIB_USEDEP}] to pdepend to ensure normal icon themes
+  (png/svg) can always be loaded (bug #547710, thanks to haarp and nE0sIghT).

+ commit e7758a4ed2669d32965e342422ca2b7f09723d25
+ Author: Alexandre Rostovtsev <tetromino@gentoo.org>
+ Date:   Sat Apr 25 14:48:11 2015 -0400
+ 
+     x11-libs/gtk+: sync deps with gx86 (bug #547710)
+     
+     Package-Manager: portage-2.2.18
+     Manifest-Sign-Key: 0x18E5B6F2D8D5EC8D
Comment 9 haarp 2015-04-26 05:14:05 UTC
Excellent, thanks!