Re: Updating the icon cache (GNOME Goals)

Federico Mena Quintero wrote:
> Hi,
> I just saw this 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.
> 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.)

Yes, %posttrans is the best way to do it (on upgrade or new
installation). On package removal, you need to call it in %postun (or
%postuntrans) conditionally as well to remove obsolete entries.

I see very important drawbacks of doing it on per-package basis:
- Also KDE/Qt/XFCE packages need to call gtk-update-icon-cache to
  display correctly in GNOME menu.
- Increases time to install (called once per package).

Better solution would be trigger triggered by virtual symbol. I proposed
it longer time in past, but I am not sure, whether it is already
implemented. Then I see no problem to create proper RPM symbol (e. g.
has_xdg_icon) in autoreqprov script. It is still not ideal, we would
need script triggered once per transaction, not once per package.

%posttrans works with following limitations:
- Not implemented in older versions of RPM.
- Less old RPM call %posttrans even for "rpm --test", so there are
  needed hacks to work-aroud this problem.
- AFAIK Requires(posttrans) is not defined, but in most/all cases
  Requires(post) will do what needed.
- %preuntrans does not exist (not useful here, but would be very useful
  for gconf scriptlets, which now need ugly hacks to work correctly).

> So, do we really need this in tarballs?

Yes. It is intended for people, who install package manually directly to
live system.

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.

Best Regards / S pozdravem,

Stanislav Brabec
software developer
SUSE LINUX, s. r. o.                          e-mail: sbrabec suse cz
Lihovarská 1060/12                            tel: +420 284 028 966
190 00 Praha 9                                fax: +420 284 028 951
Czech Republic                      

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]