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
signature.asc
Description: Digital signature
