[Fedora-packaging] Re: icon cache scriplets, using %posttrans

[Rex Dieter]

Rex Dieter wrote:
> Callum Lerwick wrote:
>> On Wed, 2006-12-20 at 07:43 -0600, Rex Dieter wrote:
>>> Because, frankly, poo-pooing the current proposal/guidelines in favor 
>>> of some handy-wavy theoretical lacking-actual-implementation 
>>> solution, is no solution.
>>
>> Well, the point is, the current proposal does not address the "multiple
>> packages needlessly updating caches multiple times" problem at all. 
> 
> Fair enough, I'll investigate hooking into rpm's %posttrans hooks.  My 
> findings so far are promising.

How about something like this?  %posttrans operations run at the end of 
the rpm transaction(1), only the first gtk-update-icon-cache would take 
any real cpu time (subsequent runs of gtk-update-icon-cache are smart 
enough to know the cache is not stale, and run virtually instantly).

I'll look into patching xdg-icon-utils into doing a "smart" update 
operation (like gtk-update-*), but until then, we need to use 
gtk-update-icon-cache here.

##########################
%post
touch --no-create %_datadir/icons/hicolor ||:

%postun
touch --no-create %_datadir/icons/hicolor ||:

# Keep this until http://bugzilla.redhat.com/170335 is fixed
%posttrans
gtk-update-icon-cache -q %_datadir/icons/hicolor >& /dev/null ||:
##########################

In my testing using a fair-to-middlin laptop, gtk-update-icon-cache 
takes 0.5-1.0 seconds to regenerate a stale cache, so doing it this way, 
if I had to install/update 10 icon-using apps, I'd save ~5-10 seconds 
install time.  Not too shabby.

(1) This same trick could be used for other expensive scriptlet 
operations too.  ldconfig, in general, is not a good candidate for this, 
since items installed by one rpm may be needed by subsequent items 
within the same transaction.

-- Rex