[Fedora-packaging] Re: iconcache, v0.5

[Axel Thimm]

On Fri, Dec 22, 2006 at 09:23:05AM -0800, Toshio Kuratomi wrote:
> On Fri, 2006-12-22 at 09:26 -0500, Jesse Keating wrote: 
> > On Friday 22 December 2006 09:22, Rex Dieter wrote:
> > > imo, ldconfig example isn't a good one, but I get your point.
> > > Difference being here, messing with ldconfig can horribly break things.
> > >   A stale iconcache doesn't break anything, at worst only affects app
> > > startup time (a little).
> > 
> > Ah!  I missed this point.  If the above statement is true, I'm all for it.  I 
> > had thought we were going down the road of making a rule that would leave the 
> > cache unupdated period, and Some Other Process As Of Yet Unwritten would have 
> > to clean up behind us.  If this happens already, and all the end user sees is 
> > a slight delay, I'm for it.
> 
> Rex may need to correct me here but I believe with the current gtk
> package and removing the gtk-update-icon-cache calls in the %post
> scripts will create a situation where the cache is not updated
> consistently.  Only when a package that has a gtk-update-icon-cache
> scriptlet is installed/updated will the cache be updated.
> 
> The difference Rex is speaking of is the level of necessity of
> ldconfig's cache vs the iconcache.  If the iconcache is not up to date
> gtk is supposed to fall back to not using the cache.  If ldconfig's
> cache is not updated, basic pieces of the system can go boom.
> 
> That said, if we want to change the guidelines, to not require the
> iconcache is in place I'd like to see something take care of updating
> the cache if it's out of date.  So the choices I see are:
> 
> 1) Leave the guidelines the way they are.  The drawbacks have been
> stated several times with different ones being important to different
> people.
> 2) Use Rex's cron script.  This leaves a stale cache around part of the
> time but has the benefit of being written now.
> 3) Write a file watching daemon that can refresh the cache when new
> files are installed.  (This may either be a daemon specific to gtk or,
> as Havoc suggested in bugzilla, a generic daemon that can be configured
> to invoke a program when a filesystem event occurs.)

or

4) have gtk do the cache maintenance it on the fly, e.g. when an icon
is accessed gtk checks for index.theme's timestamp in the folder the
icon is in and does the equivalent to gtk-update-icon-cache in the
background?

I'd prefer that over 3) because if you have a folder inotify a daemon
you'd be running the updating again several times per larger rpm
transaction. Unless that daemon would have a wait timeout on inotifies
to collect several triggers, but then it sounds easier to do 4)

> Matthias, in the bug report it seemed that you weren't opposed to
> leaving the scriptlets out of the packages and let the icon cache go
> stale.  Is there a reason not to include the cron script as a temporary
> measure until a script to monitor for icon changes is written?

I'd also prefer a simpler packages + cron script until the "100% fix" :)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20061222/7788013b/attachment.sig>