2011/4/26 Michael Schroeder
On Tue, Apr 26, 2011 at 11:54:34AM +0200, Vincent Untz wrote:
The issue is not that gtk-update-icon-cache is slow (well, I guess it's potentially an issue to some). The issue is that it has to be called after a package installs icons. And many packages don't do that, as it's easy to forget.
Oh, in that case using the collection mechanism is fine. The only problem is, of course, that the packages won't work with older distribution versions.
The spec files would still need to add a "Collections: icon" line, wouldn't? It's still a line more than with file triggers (https://features.opensuse.org/305472), but since I don't expect them to be implemented anytime soon in RPM4* (and I suppose taking the Mandriva/RPM5 patch is out of the question) it seems like the less bad solution. Anyway if file triggers are ever implemented that specific collection could be easily disabled globally. But IMHO the cause today many packages don't call gtk-update-icon-cache is not that packagers forget. The cause to me seems to be that nobody is happy with any of the solutions... If we don't call gtk-update-icon-cache Gnome people complains, if we call it somebody else complains (installer people: https://bugzilla.novell.com/show_bug.cgi?id=395056). Until it's totally clear that tomorrow we will not change the policy, packagers will not want to do the work. * Even if here http://stick.gk2.sk/blog/2009/10/rpm-summit-at-the-opensuse-conference-2009/ it says in 2009 Panu was working on it. What happened? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org