For us it doesn't really matter because conary takes care of running
gtk-update-icon-cache when the icons in a package change or a new
package containing icons are installed.
Elliot
On Mon, 2007-08-06 at 16:44 -0500, Federico Mena Quintero wrote:
Hi,
I just saw this
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
On Mon, 2007-08-06 at 17:56 -0400, Behdad Esfahbod wrote:
The Makefile.am snippet only runs gtk-update-icon-cache if DESTDIR is
empty. The idea is that distros make install to a temporary DESTDIR and
the actual install happens later. In this case, gtk-update-icon-cache
is not called in make
On Tue, 2007-08-07 at 11:28 +0200, Stanislav Brabec wrote:
And absolutelly ideal would be a new auto* standard:
If package needs special action for installation/upgrade/removal,
specially named file containing these commands will be created.
Ooooh, this is a very nice idea. Does anyone
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
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.
On Mon, 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
