Hi list, there is an ongoing disagreement in the GNOME team about the handling of icon caches, and we (or at least, I) would appreciate more input. Let me try to sum it up.
1. The issue Desktop environment and applications are using more and more icons, for many reasons. They are put in /usr/share/icons/$theme/$size/$purpose/ directories. This way, an application looking for an icon will have to look through the whole directory structure of /usr/share/icons/$theme for the current theme and all themes it inherits from. This is very slow. 2. The cure A mmap()-able cache file format was proposed, and is generated by gtk-update-icon-cache in /usr/share/icons/$theme/icon-theme.cache files. It helps a lot to improve speed. 3. The side-effect (for an euphemism) The current code in GTK+ follows the freedesktop.org specification: if the mtime of /usr/share/icons/$theme/ is more recent than that of icon-theme.cache, the cache is considered outdated, and the whole directory structure is read instead. As a result, if an application installs a new icon, of course the mtime of a directory two levels up isn't changed. When started, the application doesn't find the icon. Some applications only become ugly, some simply refuse to launch. 4. The current state of affairs In sarge - and this is still the case in unstable - the icon cache is generated for most themes, but not for "gnome" and "hicolor", which are the default directories applications install icons in. That means some themes in gnome-themes-extras (which don't inherit from gnome) benefit from the icon cache, but other themes (especially the default) don't. 5. The proposed solution The Redhat people, who implemented the cache specification, obviously don't have problems with applications suddenly becoming unusable after some change: they started to generate cache for all directories, automatically adding post-installation snippets to the application packages. As "this worked", and as the GTK+ developers - which happen to be partly the same people - don't want to change the code, their recommendation is to do the same for Debian. Applying this solution means that, as soon as some packages start using the new debhelper snippet, hundreds of other packages will more or less break when installed after the cache generation. In short, some people in the GNOME team want to apply this solution nevertheless, while other people (including me) don't want of it. Alternative proposed solutions are to keep things as they are in sarge, or to change the code to check for the mtime's of all subdirectories (which of course would be slower). I'm not searching for support here, but for a decision. If a consensus about applying it arises, I'll apply it - I even already started to write the debhelper script. Regards, -- .''`. Josselin Mouette /\./\ : :' : [EMAIL PROTECTED] `. `' [EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]