Bug 6729 (int-150694)

Summary:	gtk-update-icon-cache -f shouldn't say Failed to open file /usr/share/icons/hicolor/.icon-theme.cache : File exists
Product:	[Maemo Official Platform] Desktop platform	Reporter:	timeless
Component:	gtk	Assignee:	unassigned <nobody>
Status:	RESOLVED WORKSFORME	QA Contact:	gtk-bugs
Severity:	normal
Priority:	Low	CC:	andre_klapper, urho.konttori
Version:	5.0/(1.2009.42-11)
Target Milestone:	5.0/(1.2009.44-1)
Hardware:	All
OS:	All
Bug Depends on:
Bug Blocks:	6931
Attachments:	log

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.