Some news of GNOME to Ubuntu:
* After the previous blog discussion about Ubuntu not using the GTK icon cache, dholbach pinged me saying he wrote the small build changes required to automatically update the cache for most of the GNOME packages on Ubuntu. The issue was the number of rebuilds rather than the lack of tools, but since he started on it we decided to go with the rebuild way just before GNOME 2.14.1. Daniel uploaded his changes and made a list of packages to build on the wik., and since we rebuilt most of GNOME for the new version, now Ubuntu does use the GTK icon cache too!
* GNOME 2.14.1 has been uploaded to dapper this week and will be the version used for the dapper beta CD next week. The Ubuntu Desktop Team still gets load of bugs, thank you for the bugsquad people who work with us to keep up with them, the dapper desktop will rock! The beta CD that will be rolled next week is probably a good occasion for you to play with dapper if you had planned to do so. There is still some bugs that would be nice to fix before dapper, so if you want to participate feel free to send patches or join the discussions on IRC or on the desktop-list by example
* A new rhythmbox tarball (0.9.4) has been rolled today. We have no plan to ship it with dapper for the moment but I’ve uploaded a package (source and i386) on http://people.ubuntu.com/~seb128/deb (works as an apt source too) for those who want to play with the new version (there are also some gaim 2.0beta3 packages at the same place)
According to BenM, Ubuntu not using the GTK icon cache is a packaging bug. That is just wrong. The icon cache is used for the different themes, “just” not for “gnome” nor “hicolor”. Why not using it for them? Because the Debian GNOME maintainers consider the cache implementation as bugged at the moment. That has been discussed upstream and marked as NOTABUG.
The issue is that if your package doesn’t “touch theme_dir” the cache just “masks the icon”. According to the comment from dholbach, Ubuntu Dapper has 346 packages that would require to be updated for that. Knowing that some applications don’t like to have their icons “not installed” and just crash, that can quickly start beeing annoying for an user (you can discuss that the app should not have an issue with that, the fact is many of them do)
So from the moment you generate the icon cache from one package, you “break” the 345 other distribution packages until they are updated, and probably other packages distributed upstream, etc. If an user install any of those packages not updated or not shipped by the distribution itself he’s likely to face a stability issue.
The Debian GNOME maintainers have decided it would be better to make that cache robust before using it. I think it would be reasonable to retry without the cache when the icon is not found from the cache (it would only mean being slower for non-updated packages or applications instead of facing bugs because the application expects to be correctly installed)
BenM, you ask what you can make sure than every distro take advantage of the performance work? Maybe upstream listening to them, when they say they will not use the current implementation, instead of rejection the discussion as NOTABUG would be a first step. Making the icon cache robust would be better for sure