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
On Wed, 2006-12-20 at 11:42 -0600, Rex Dieter wrote:
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).
The problem is that this is still just working around the problem... if we start moving towards doing multiple transactions[1], then the script starts to run more times and we can watch the benefit start to dwindle.
I think instead of doing a paper-over fix like this, we really need to look at the cases that scriptlets are used in and see if there's a way to have a "smarter scriptlet"[2] with rpm moving forward
Jeremy
[1] There are definitely advantages as far as memory usage in doing this as well as resiliency to things "going wrong" during the transaction. I'm not sure what the real effect on time would be of doing so. It's definitely something that I at least want to do more investigation of [2] This is one of the things that I think conary has gotten right :-)
Jeremy Katz wrote:
On Wed, 2006-12-20 at 11:42 -0600, Rex Dieter wrote:
Rex Dieter wrote:
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).
The problem is that this is still just working around the problem...
Of course it's a workaround!
Modulo workarounds, I'm back to advocating dropping gtk-update-icon-cache from scriptlet guidelines altogether, effectively forcing issue wrt existing gtk2 packaging bug, ie, gtk2 currently contains no mechanism to create/refresh it's own icon cache.
-- Rex
packaging@lists.fedoraproject.org
-
Jeremy Katz -
Rex Dieter