gtk-update-icon-cache not run

this is not a bug, the cache works by folder and is updated by the theme when
they are installed.

With the current cache implementation it's not easy to make a cache for hicolor
by example, for this reason:
- you do a cache for /usr/share/icons/hicolor
- gtk compares the cache and the directory mtimes to know if the cache is outdated
- if it's not outdated it uses the cache
- now you install an icon to /usr/share/icons/hicolor/48x48/apps/, the mtime for
/usr/share/icons/hicolor is not updated
- the cache masks this new icon

Basically the cache to work would require to patch every single package
installing an icon to update the directory too which is not the case at the moment.

"This caching can make it impossible for users to add icons without having to
restart applications. In order to handle this, any implementation that does
caching is required to look at the mtime of the toplevel icon directories when
doing a cache lookup, unless it already did so less than 5 seconds ago. This
means that any icon editor or theme installation program need only to change the
mtime of the the toplevel directory where it changed the theme to make sure that
the new icons will eventually get used."

http://cvs.fedora.redhat.com/viewcvs/devel/gnome-panel/gnome-panel.spec?rev=1.68&view=auto
gives a correct example of the impl of the spec in an rpm format:

%post
touch --no-create %{_datadir}/icons/hicolor
if [ -x /usr/bin/gtk-update-icon-cache ]; then
  gtk-update-icon-cache -q %{_datadir}/icons/hicolor
fi

Given the huge benefit, it seems worth a small audit to get this correct.

Thanks for the followup.

The issue is not the audit, it's to rebuild hundreds (thousands?) of packages to
use this hack. We started this discussion with Debian/GNOME maintainer some time
ago but stopped because changing this number of package before Sarge was not an
option.

I'll ping them again about this, but from the previous discussion some of them
where not really happy of the way how the cache works, they would prefer to look
on the mtime of all the subdirs (which should be quite fast too and robust).

http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=usr%2Fshare%2Ficons%2Fhicolor&searchmode=searchfilesanddirs&case=insensitive&version=hoary&arch=i386&page=1&number=all

Has a list of pacakges that install stuff into /usr/share/icons/hicolor. I
copied and pasted the list into a text editor and did:

[benm@omega benm]$ cat icons-list | awk '{ print $2 }' | sort | uniq | wc -l
138

right, that's only for hicolor but most of icon are here. That's a bunch of
package but should not be an issue, I'll talk to Debian guy and start working on
that next week, thanks for your attention on the issue.

That was for hoary, for Dapper it is: 346

Does anyone know what the status of this bug is? From what I understand, this would fix the loading times of icons in a lot of menus, speeding up a lot of older computers by a lot...

For Dapper and 'GNOME' it's: 10

i agree with some that comment that the cache specification is broken.
there is an alternative to patching the 300+ packages: patch the cache to:
1. retry on the filesystem if the icon wasn't found in the cache (as sebastien bacher suggested on planet gnome)
2. check recursively the mtime to decide whether the cache is outdated

so that's the alternative for ubuntu & debian: patch the cache instead of disabling it, even if upstream disagrees. 1 package to change instead of 300+ and of course rebuild applications to use the cache, which would be needed anyway.
of course that risks some bad mood & bad comments from upstream...

For GNOME and hicolor, it's: 205 source packages, 60 in main.

Transition has been made, that bug is fixed with dapper