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