On E, 2007-08-06 at 16:44 -0500, Federico Mena Quintero wrote: > Hi, > > I just saw this http://live.gnome.org/GnomeGoals/AppIcon about making > apps update the GTK+ icon cache during "make install". > > This would be fine in a tarball-only world, but I wonder if distros will > just end up patching out that part of Makefiles, and calling > gtk-update-icon-cache on their own. There is no reason for us at least, because all the updating of gtk icon cache in Makefiles that I've seen is conditional on DESTDIR not being set, but as we do set DESTDIR for obvious reasons, the icon cache update in tarball doesn't get called and we can do it as necessary in our equivalent of what is used in openSUSE (pkg_postinst and pkg_postrm). > For example, in openSUSE we update the icon cache separately from > package installation, with the idea that the cache will only be updated > once even if many packages are installed. (The really right way may be > to use an RPM %posttrans - no idea if that works.) > > So, do we really need this in tarballs? If it helps installers from tarballs, then why not? For distributions I don't see any difference myself, as I can imagine most of them will have to set DESTDIR. So I would ask instead if it is that important then as a GnomeGoal. I think it's possibly nice for tarball users, but I can't estimate how many of those are there. jhbuild maybe falls under it somehow, as this isn't just about tarballs having it but also SVN? If so, then they are to benefit from it if it doesn't set DESTDIR, but just PREFIX. -- Mart Raudsepp Gentoo Developer Mail: leio gentoo org Weblog: http://planet.gentoo.org/developers/leio
Attachment:
signature.asc
Description: This is a digitally signed message part