Hi. So today I decided to unslack and finally do what I had in mind since more than a year... I have added a -guic subpackage to x11/gtk+2 that provides the gtk-update-icon-cache utility. This utility only depends on gdk_pixbuf2 and glib2. Until today we used not to enforce dependency on gtk-update-icon-cache because it was part of gtk+2 which would make no sense for some ports. Also that means that gtk+3 no longer depends on gtk+2.
Starting today, any port that installs files under share/icons/*/... needs the following: * add dependency on gtk-update-icon-cache RUN_DEPENDS += x11/gtk+2,-guic * run gtk-update-icon-cache; a typical example would be: @exec %D/bin/gtk-update-icon-cache -q %D/share/icons/hicolor 2>/dev/null || true @unexec-delete %D/bin/gtk-update-icon-cache -q %D/share/icons/hicolor 2>/dev/null || true Beware that these exec have changed from what we used to run, we are not forcing the generation of the cache file anymore if it's up-to-date which should save a couple of seconds here and there. If a port uses the x11/gnome or x11/xfce4 MODULE it needs to set the following variable to "Yes" instead of adding the RUN_DEPENDS line: MODGNOME_ICON_CACHE = Yes MODXFCE_ICON_CACHE = Yes Also, there shouldn't be any need for a port to depends on x11/hicolor-icon-theme (the gtk+ ports are an exception); it probably just means they are installing icon files in which case adding x11/gtk+2,-guic to the RUN_DEPENDS will be enough (gtk-update-icon-cache depends on x11/hicolor-icon-theme already). When the gtk-update-icon-cache gets updated, it will regenerate all icons cache. Any question or fallout from this change, please contact me. Thanks. -- Antoine
