Bug#407837: gtk icon cache transition problems

[Joey Hess]

Package: libgtk2.0-bin
Version: 2.8.20-4
Severity: normal

As mentioned in #369755:

 It is interesting to note that the icon cache approach breaks backward
 compatibility by not checking for real files in case of cache misses.

So currently, the first package that starts calling gtk-update-icon-cache
will break all other packages that have icons in the same directory, since
the cache won't be updated when their icons are added/changed. So we can't
make any package use gtk-update-icon-cache. As it stands, some kind of flag
day event is called for. Again quoting #369755:

 This means that there will be a large transition period to add the icon
 cache updating flag.

 Instead of adding to debhelper now, and instantly creating a source of
 pixmaps/icons bugs, I propose introducing a common postinst snipset in
 a shared package (perhaps a desktop-common-postinst package or a
 foobarhelper) where we could switch a flag on to switch to the gtk icon
 cache world.
   This would permit preparing all apps first, then making the
 transition transparently.

Flag days and major transitions are painful and should be avoided if
possible. I can see four approaches:

1. Modify the icon cache code to look for real files if there is a cache
   miss. Then we would not need a flag day. 
2. Move icons to some other directory, and cache those in the new directory,
   but not those in the old. Could be a problem since icon directories are
   semi-standardised.
3. Go with the flag idea suggested above. But examination of my system
   suggests that some packages are already using gtk-update-icon-cache.
   For example, I have a /usr/share/icons/hicolor/icon-theme.cache, last
   updated Jul 30 2006, that must have been created by some rogue package.
   For the flag idea to be effective, it should completely disable use of
   gtk-update-icon-cache on a directory, which suggests to me that
   gtk-update-icon-cache itself should check for the flag.
4. File bugs on everything to start using it ASAP, ignoring the transition.

It seems like #4 is going to happen by default if nothing continues to be
done about this issue. Is #1 feasable? What about #3?

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20070121/5c04535e/attachment.pgp