[Portland] gtk-update-icon-cache problems.

[Bastian, Waldo]

>Per Olofsson notices in
>https://bugs.freedesktop.org/show_bug.cgi?id=8153
>> The script xdg-icon-resource tries to create a GTK icon cache when
>> installing icons. The problem here is that there might not have been
>an
>> icon cache there in the first place.
>>
>> Suppose then that another package installs an icon, but does not
>update
>> the icon cache (this happens frequently in Debian). Then GTK will not
>see
>> the new icon because it uses the outdated cache. Thus,
>xdg-icon-resource
>> breaks unrelated packages.
>>
>> My proposal for fixing this is to check if a cache exists before
>trying to
>> update it.
>
>However, testing with Debian testing/Gnome 2.14 shows that
>/usr/share/icons/hicolor does not have an icons.cache (most themes
have,
>but gnome, hicolor and default do not) and without running
>gtk-update-icon-cache nautilus fails to find new icons installed in
>hicolor.
>
>What is the correct thing to do here? I'm inclined to think that
>gtk-update-icon-cache should always be run and that packages that fail
>to run gtk-update-icon-cache themselves are simply broken.

Replying to myself :-} touching the /usr/share/icons/hicolor direcotry
seems to help nautilus if there isn't a cache... There still seems to be
a bit of a racecondition going on, but I have the impression that
nautilus picks up the right icon most of the time now in my test case.

Cheers,
Waldo