This is an old issue that is facing Gentoo for years. We rely on packages using gnome2.eclass to finally update icon caches via gnome2_icon_cache_update from gnome2-utils.eclass. The problem of this approach is that most packages outside gnome world (those not using gnome2.eclass) are usually forgetting to inherit gnome2-utils.eclass to call gnome2_icon_cache_update. Also, this cache is not only used by gnome, it seems to be also used by other GTK based desktops like XFCE (for example bug 564436 shows the usual problem of icons not appearing because of not running this). The idea would be that, in the future, packages providing XDG desktop files (that most of the times rely on icons installed under /usr/share/icons/hicolor) get this cache updated "automatically" when gtk-update-icon-cache is present on their systems. This would be more easy than asking all the packages installing this icons to remember to add a pkg_postinst and pkg_postrm manually calling gnome2_pkg_postinst and xdg_pkg_pre/postinst (this making xdg.eclass a bit useless as we need to not rely on their default phases because of this issue). The idea would be to try to do this for next EAPI, to allow us to move this logic to xdg eclasses from "gnome" ones
By the way, even recent versions of Qt use this icon cache too.
The only required dependency is gtk-update-icon-cache which is standalone binary extracted from gtk+ sources depending on glib and gdk-pixbuf for obvious reasons. Do you think this should be added to dependencies of xdg.eclass. This migration was delayed when writing xdg*.eclass originally as the package was not split yet.
I think it'd be OK to just only do the calls if the update binary is present, and we'll have gtk+ and qt5 or whatever pull the package in? Though it doesn't allow for proper build time dependency due to lack of recursive build deps, so not sure because of that. In that way maybe the dep should be fine, as the eclass will have it as build time only and people can just remove it afterwards? But might have purists want to not have it when inherited for a package with USE=X or USE=gtk or whatever. </random thought dump>
I'd like this settled as we introduce a gnome-meson.eclass or maybe even it could be universal meson-desktop.eclass.
(In reply to Mart Raudsepp from comment #3) The command is run from pkg_postinst, so any dependency belongs in RDEPEND (run-time), not DEPEND (build-time). Portage ignores DEPEND entirely when installing from a binpkg.
Then the current eclass has this problem as well. I certainly don't think that cache files generators should be RDEPENDs but they should be available at postinst, otherwise we are kinda screwed.
One could also use automatic triggers https://wiki.gentoo.org/wiki/Future_EAPI/Triggers
(In reply to Jonas Stein from comment #7) > One could also use automatic triggers > https://wiki.gentoo.org/wiki/Future_EAPI/Triggers If they'd exist.. they don't. While working with some other stuff than gnome2.eclass using things, it's now often that I need to just inherit xdg and then still override preinst and postinst to add icon-cache calls. We should get this into xdg ASAP indeed imho, preferably before or as we get some gnome-meson.eclass or meson-desktop.eclass into main tree (if that ends up necessary at all after icon cache gets into xdg...). One thing I was thinking about is - should we be making some sort of mechanism to avoid double-calling this (and log a eqawarn), because many places already inherit xdg and then call icon cache update as well, so if xdg does it itself, they'll be double calls, in addition to all the calls for each package when only once in a while from triggers would be sufficient. Or if we should just ignore the double calls and start removing the manual ones ASAP instead.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a506c07df071f68613099e8b7e2b1f81c9ef97a1 gnome2-utils: move icon functions into xdg-utils Kept some dummy stub functions in place in order to maintain functionality of existing ebuilds. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0d3868010666fe2ce95c307028b42d401da73d67 gnome2.eclass: move icon handling code to xdg.eclass https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8d89c4d87d51c3d07ebcdc916b046ea9726abe8b xdg-utils: Clarify icon cache comment to not suggest GTK only
(In reply to Mart Raudsepp from comment #3) > I think it'd be OK to just only do the calls if the update binary is > present, and we'll have gtk+ and qt5 or whatever pull the package in? Though > it doesn't allow for proper build time dependency due to lack of recursive > build deps, so not sure because of that. In that way maybe the dep should be > fine, as the eclass will have it as build time only and people can just > remove it afterwards? But might have purists want to not have it when > inherited for a package with USE=X or USE=gtk or whatever. > > </random thought dump> @qt: what do you think of the above? These eclass patches didn't add a gtk-update-icon-cache depend on purpose; should qtgui or whatever uses the cache RDEPEND on it instead as I suggested in comment #3 or do you have other ideas?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/qt.git/commit/?id=174602961b5f4c28bda4c1a5bf2c2fd18cbda8a8 commit 174602961b5f4c28bda4c1a5bf2c2fd18cbda8a8 Author: Michael Palimaka <kensington@gentoo.org> AuthorDate: 2019-05-18 02:38:16 +0000 Commit: Michael Palimaka <kensington@gentoo.org> CommitDate: 2019-05-18 02:38:23 +0000 dev-qt/qtgui: add dependency on dev-util/gtk-update-icon-cache Bug: https://bugs.gentoo.org/640020 Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: Michael Palimaka <kensington@gentoo.org> dev-qt/qtgui/qtgui-5.12.9999.ebuild | 1 + dev-qt/qtgui/qtgui-5.13.9999.ebuild | 1 + dev-qt/qtgui/qtgui-5.9999.ebuild | 1 + 3 files changed, 3 insertions(+)
