Change:
### Icons {#ssec-gnome-icons} <del> When an application uses icons, an icon theme should be available in `XDG_DATA_DIRS` during runtime. The package for the default, icon-less [hicolor-icon-theme](https://www.freedesktop.org/wiki/Software/icon-theme/) (should be propagated by every icon theme) contains [a setup hook](#ssec-gnome-hooks-hicolor-icon-theme) that will pick up icon themes from `buildInputs` and pass it to our wrapper. Unfortunately, relying on that would mean every user has to download the theme included in the package expression no matter their preference. For that reason, we leave the installation of icon theme on the user. If you use one of the desktop environments, you probably already have an icon theme installed. </del> <ins> When an application uses icons, an icon theme should be available in `XDG_DATA_DIRS` during runtime. The package for the default, icon-less [hicolor-icon-theme](https://www.freedesktop.org/wiki/Software/icon-theme/) (should be propagated by every icon theme) contains [a setup hook](#ssec-gnome-hooks-hicolor-icon-theme) that will pick up icon themes from `buildInputs` and add their datadirs to `XDG_ICON_DIRS` environment variable (this is Nixpkgs specific, not actually a XDG standard variable). Unfortunately, relying on that would mean every user has to download the theme included in the package expression no matter their preference. For that reason, we leave the installation of icon theme on the user. If you use one of the desktop environments, you probably already have an icon theme installed. In the rare case you need to use icons from dependencies (e.g. when an app forces an icon theme), you can use the following to pick them up: ```nix buildInputs = [ pantheon.elementary-icon-theme ]; preFixup = '' gappsWrapperArgs+=( # The icon theme is hardcoded. --prefix XDG_DATA_DIRS : "$XDG_ICON_DIRS" ) ''; ``` </ins> To avoid costly file system access when locating icons, GTK, [as well as Qt](https://woboq.com/blog/qicon-reads-gtk-icon-cache-in-qt57.html), can rely on `icon-theme.cache` files from the themes' top-level directories. These files are generated using `gtk-update-icon-cache`, which is expected to be run whenever an icon is added or removed to an icon theme (typically an application icon into `hicolor` theme) and some programs do indeed run this after icon installation. However, since packages are installed into their own prefix by Nix, this would lead to conflicts. For that reason, `gtk3` provides a [setup hook](#ssec-gnome-hooks-gtk-drop-icon-theme-cache) that will clean the file from installation. Since most applications only ship their own icon that will be loaded on start-up, it should not affect them too much. On the other hand, icon themes are much larger and more widely used so we need to cache them. Because we recommend installing icon themes globally, we will generate the cache files from all packages in a profile using a NixOS module. You can enable the cache generation using `gtk.iconCache.enable` option if your desktop environment does not already do that.

Discussion:
It seems, inkscape is a build-only dependency of mate-utils, but wrapGAppHook makes it a runtime dependency Steps to reproduce the behavior: mate-utils mate-utils doesn't pull inkscape
In fact appears in the binary wrappers, in the definition of . Not being a runtime dependence, it should not. I suppose this should be fixed in .
By runtime dependency I mean it's installed with binary package
In the derivation it appears in , making it a build dependence. Probably the fact that it is mentioned in the binary wrappers created by has the consequence of turning it into a runtime dependence.
Yeah, I see :( Who is maintainer of wrapGAppsHook though? I wanted initially to mention them in the issue, but unable to find that information
cc
Looking at the output of , it probably gets picked up by puts to inside .
I am not sure why would we even want to add the data directories of icon dependencies into . The app’s own icons should be covered by , and adding icon themes like will not work unless the user also configures the system to use that theme (in which case they should have the theme installed). Or the package contains icons in the fallback () theme – but that should mostly just contain application icons (not something most apps would want to use).
I know Qt has QIcon::setThemeName API, so if gtk has something similar, applications can distribute their own icons in separate packages and then pick up with such API
Sure, but I would not expect that to be common – not even Pantheon does that.
So I would suggest just removing this code: It can cause unintended fallout in cases where it picks up stuff like Vala vapi files but I would expect it to be pretty minor – exists mostly just in app packages, not libraries.
Closing since it sounds like this was fixed by the merge of Happy to reopen if I'm mistaken.