maemo.org Bugzilla – Bug 6729
gtk-update-icon-cache -f shouldn't say Failed to open file /usr/share/icons/hicolor/.icon-theme.cache : File exists
Last modified: 2010-10-25 18:47:48 UTC
You need to
before you can comment on or make changes to this bug.
EXACT STEPS LEADING TO PROBLEM:
0. have both /usr/share/icons/hicolor/.icon-theme.cache and
1. try to install pidgin using hildon application manager (pidgin's postinst
runs gtk-update-icon-cache -f /usr/share/icons/hicolor)
gtk-update-icon-cache -f shouldn't care if
Failed to open file /usr/share/icons/hicolor/.icon-theme.cache : File exists
and postinst fails, which means pidgin and dependents don't configure properly
always as long as both files exist (deleting .icon-theme.cache fixes this
EXTRA SOFTWARE INSTALLED:
vpnc and enus1
Created an attachment (id=1694) [details]
(In reply to comment #0)
> EXACT STEPS LEADING TO PROBLEM:
> 0. have both /usr/share/icons/hicolor/.icon-theme.cache and
How? I have none of them.
gtk-update-icon-cache -f /usr/share/icons/hicolor
will create one of them (and then probably move it to replace the other),
pidgin seems to have ~3 related packages each of which will create that file in
postinst. I'm not quite sure what would cause both of them to exist, my guess
is a reboot or similar before the rename done by gtk-update-icon-cache happens.
Given that the -f for gtk-update-icon-cache means 'force', it seems reasonable
to assert that it shouldn't fail just because that file exists. I suppose
there's an interesting race condition between multiple concurrent
gtk-update-icon-cache -f's being run, however i claim that's not interesting,
dpkg will generally serialize installs and if an actual user wants to shoot
self in foot by using -f in two processes at the same time, that's user error.
However, as is, the only workaround is for each package which uses this app to
also rm -f $FOO/.icon-theme.cache which seems inappropriate.
this was "fixed" (for fremantle something) by:
which is supposedly in
libgtk2.0-bin 2:2.14.7-1maemo12-2 or higher.
the "fix" neutralizes the script, so presumably it's still broken upstream.
icon cache is not needed anymore, so it has been dropped from pr1.0.1 onwards.