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