Bug 6729 - (int-150694) gtk-update-icon-cache -f shouldn't say Failed to open file /usr/share/icons/hicolor/.icon-theme.cache : File exists
(int-150694)
: gtk-update-icon-cache -f shouldn't say Failed to open file /usr/share/icons/h...
Status: RESOLVED WORKSFORME
Product: Desktop platform
gtk
: 5.0/(1.2009.42-11)
: All All
: Low normal (vote)
: 5.0/(1.2009.44-1)
Assigned To: unassigned
: gtk-bugs
:
:
:
: int-136782
  Show dependency tree
 
Reported: 2009-12-08 18:56 UTC by timeless
Modified: 2010-10-25 18:47 UTC (History)
2 users (show)

See Also:


Attachments
log (834 bytes, text/plain)
2009-12-08 18:56 UTC, timeless
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description timeless (reporter) 2009-12-08 18:56:44 UTC
EXACT STEPS LEADING TO PROBLEM: 
0. have both /usr/share/icons/hicolor/.icon-theme.cache and
/usr/share/icons/hicolor/icon-theme.cache
1. try to install pidgin using hildon application manager (pidgin's postinst
runs gtk-update-icon-cache -f /usr/share/icons/hicolor)

EXPECTED OUTCOME:
gtk-update-icon-cache -f shouldn't care if
/usr/share/icons/hicolor/.icon-theme.cache exists

ACTUAL OUTCOME:
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

REPRODUCIBILITY:
always as long as both files exist (deleting .icon-theme.cache fixes this
"problem")

EXTRA SOFTWARE INSTALLED:
vpnc and enus1
Comment 1 timeless (reporter) 2009-12-08 18:56:58 UTC
Created an attachment (id=1694) [details]
log
Comment 2 Andre Klapper maemo.org 2009-12-08 19:56:22 UTC
(In reply to comment #0)
> EXACT STEPS LEADING TO PROBLEM: 
> 0. have both /usr/share/icons/hicolor/.icon-theme.cache and
> /usr/share/icons/hicolor/icon-theme.cache

How? I have none of them.
Comment 3 timeless (reporter) 2009-12-08 21:05:05 UTC
well:
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.
Comment 4 timeless (reporter) 2009-12-15 14:25:40 UTC
this was "fixed" (for fremantle something) by:
http://www.gossamer-threads.com/lists/maemo/commits/55502?search_string=icon%20cache;#55502

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.
Comment 5 Urho Konttori 2009-12-21 12:00:28 UTC
icon cache is not needed anymore, so it has been dropped from pr1.0.1 onwards.