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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
