Bug 170335

Summary: gtk2: create/maintain icon cache
Product: [Fedora] Fedora Reporter: Rex Dieter <rdieter>
Component: gtk2Assignee: Matthias Clasen <mclasen>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: bugs.michael, davidz, dennis, gajownik, gauret, lmacken, mgarski, tibbs, toshio, wtogami
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-21 10:36:20 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 206860    
Bug Blocks: 235705    
Attachments:
Description Flags
patch
none
more robust patch none

Description Rex Dieter 2005-10-10 15:25:45 EDT
It would ease packagers' burden to not have to run gtk-update-icon-cache for
*every single* application that installs icons.  This could easily be avoided if:

1. gtk-update-icon-cache would be run via a periodic (daily?) cron-job, 
2. fall back to (pre gtk-update-icon-cache behavior) file system search if icon
is not found in-cache
Comment 1 Rex Dieter 2005-10-22 09:17:12 EDT
Ignore 2, it is already handled properly (if packages touch the top-level icon
theme dir as dictated by the icon-spec).

Running gtk-update-icon-cache as a periodic cronjob is/should-be, IMO,
essential.  Why burden 100's of rpm's to have to run it in %%post/%%postun when
it could simply be handled here (in gtk2)
Comment 2 Rex Dieter 2006-02-02 16:48:57 EST
Here's a sample implementation (3 lines):
#!/bin/sh

foreach icon_theme in /usr/share/icons/*/index.theme ; do
   /usr/bin/gtk-update-icon-cache -q `dirname ${icon_theme}` ||:
done

IMO, this should also be in %post to ensure existing icon themes get cached on
gtk2's initial install.
Comment 3 Enrico Scholz 2006-02-03 15:32:33 EST
A cronjob which updates content under /usr regularly, sounds like a really bad
idea to me. When the caching would be changed to look for the icon-cache under
/var, it would be fine with me. A quick&dirty (or well-designed&clean) solutions
might be symlinks like /usr/share/icons/.../.icon-cache ->
/var/cache/icon-cache/usr_share_icons_..._icon-cache and 'gtk-update-icon-cache'
writes either directly into this file or reads the symlink and recreates it.


Else, are you sure that all possible icon-directories can be enumerated in this
way? (thtat's not a critic, I just do not know it ;))
Comment 4 Matthias Clasen 2006-02-03 15:39:29 EST
I'd be really wary of changing the location of the icon cache files. 

a) it is specified in the icon theme spec

b) look how well the transition to /var/cache went for fontconfig...
Comment 5 Rex Dieter 2006-02-03 16:27:59 EST
>I'd be really wary of changing the location of the icon cache files. 
> a) it is specified in the icon theme spec

Not sure to which spec you're referring, because
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
certainly makes no mention of cache file name or location.
Comment 6 Matthias Clasen 2006-02-03 16:40:11 EST
Hmm, we probably never added it back to the spec.
Comment 7 Rex Dieter 2006-02-03 21:41:35 EST
Added it back?  I don't see it appearing in *any* version of the spec.

Regardless, unless there is momentum to actually make this a standard, it
should, IMO, be treated as a gtk-only/proprietary implementation.  

As such, apps/packaging (*especially* non-gtk ones) should not be burdened with
the task of supporting it.  Implementing the cache update in cron and in %post
here in gtk2 packaging, as I have suggested, would accomplish this.

> are you sure that all possible icon-directories can be 
> enumerated in this way?

Not 100%, but it's at least a start, and can easily be incrementally expanded or
improved upon.
Comment 8 Rex Dieter 2006-06-20 15:17:38 EDT
Retargeting devel, let's see if this can make fc6.
Comment 9 Rex Dieter 2006-06-20 15:36:25 EDT
Here's another crack at a potential cron script that even respects the value of
XDG_DATA_DIRS (see http://standards.freedesktop.org/basedir-spec/0.6/ar01s03.html)

#!/bin/bash

DATA_DIRS=$(echo ${XDG_DATA_DIRS:-/usr/local/share:/usr/share} | tr ':' ' ')
for DIR in ${DATA_DIRS} ; do
  if [ -d "$DIR/icons" ]; then
    ICON_THEMES="$(find ${DIR}/icons -type f -name 'index.theme' -maxdepth 2
2>/dev/null)"
      if [ ! -z "$ICON_THEMES" ]; then
        for ICON_THEME in $ICON_THEMES ; do
          ICON_DIR=$(dirname $ICON_THEME)
          /usr/bin/gtk-update-icon-cache -q $ICON_DIR ||:
        done
      fi
  fi
done

could even put in a test to see if the index.theme is older than $ICON_DIR, but
I'm assuming gtk-update-icon-cache already does that.  (:
Comment 10 Rex Dieter 2006-07-24 17:14:44 EDT
ping, pretty please with sugar on top, can this make fc6?
Comment 11 Dennis Gilmore 2006-07-24 18:01:08 EDT
+1
Comment 12 Matthias Clasen 2006-07-24 18:56:16 EDT
Unfortunately, it didn't...
Comment 13 Rex Dieter 2006-07-25 16:32:29 EDT
Just because it's not in now (presumably for fc6t2), doesn't preclude this being
included in fc6(final) and/or an update for fc6, does it?
Comment 14 Dennis Gilmore 2006-07-25 16:49:20 EDT
or going in for fc6 test3 It would be really nice to get it in very soon so 
that it can be thoroughly tested before fc6  is baked

Comment 15 Matthias Clasen 2006-07-25 21:24:18 EDT
I don't believe a cron job is the solution for this "problem", really.
If you remove the cache regeneration from the %post scripts, and rely on 
a cron job to do it every night, the caches may be stale 90% of the time
for somebody who updates regularly. 

A working post-transaction hook in rpm would be a much better solution.
Comment 16 Rex Dieter 2006-07-25 21:39:47 EDT
> the caches may be stale 90% of the time
> for somebody who updates regularly. 
Heck, put the sucker in /etc/cron.hourly/ then.

> A working post-transaction hook in rpm would be a much better solution.

So basically, the status-quo?

Better solution for you maybe, but not for packagers.  Are you serious?  You'd
rather inflict this packaging hassle/pain (ie, push off the job of running
gtk2-update-icon-cache) onto *every* single pkg installing icons?  This is
literally 100's of packages.  
Comment 17 Toshio Kuratomi 2006-07-26 12:42:34 EDT
(In reply to comment #16)
> > the caches may be stale 90% of the time
> > for somebody who updates regularly. 
> Heck, put the sucker in /etc/cron.hourly/ then.
> 
> > A working post-transaction hook in rpm would be a much better solution.
> 
> So basically, the status-quo?
>
The status quo is broken.  Calling gtk-update-icon-cache from the gtk2 %post
will at least fix the issue of the cache not existing when gtk2 is installed
after packages containing icons.

> Better solution for you maybe, but not for packagers.  Are you serious?  You'd
> rather inflict this packaging hassle/pain (ie, push off the job of running
> gtk2-update-icon-cache) onto *every* single pkg installing icons?  This is
> literally 100's of packages.  

This is a bit of an annoyance.  If the hourly cron script is considered too
delayed, how about a little gamin script in python that invokes
gtk-update-icon-cache as necessary?  Would that be considered too invasive
(requires a root daemon to run in the background waiting for updates)?
Comment 18 Dennis Gilmore 2006-07-26 12:57:02 EDT
someone who updates their machine regularly could also potentially run 
gtk-update-icon-cache 20 or 30 times in one update cycle currently. if there 
is a big upate. 

perhaps  a yum plugin or a rpm macro  for the end of the transaction.  so it 
gets run only once per update/install
Comment 19 Matthias Clasen 2006-07-26 17:53:36 EDT
> This is a bit of an annoyance.  If the hourly cron script is considered too
> delayed, how about a little gamin script in python that invokes
> gtk-update-icon-cache as necessary?  Would that be considered too invasive
> (requires a root daemon to run in the background waiting for updates)?

I had the thought of doing something similar in spirit, adding delayed mode
to gtk-update-icon-cache. The first call to gtk-update-icon-cache --delayed
would wait around for some time before updating the icon caches, later calls
would check if a delayed instance is already running, and just ping it to make 
it wait some more. 

Doing it this way avoids yet another daemon. 

Of course, it may be much easier and still good enough to combine a daily cron
job with a post-transaction plugin in yum.

Anyway, I don't have time to implement either solution right now, and feature
freeze for FC6 has already passed...
Comment 20 Dennis Gilmore 2006-11-28 13:52:13 EST
and this is not a bug why ?
Comment 21 Matthias Clasen 2006-11-28 13:58:30 EST
You are barking up the wrong tree. This is bug is not NOTABUG
Comment 22 Rex Dieter 2006-11-28 14:10:52 EST
hee.  "This bug is not NOTABUG", say that 10 times fast.
Comment 23 Dennis Gilmore 2006-11-28 14:11:57 EST
Sorry Matthias,  

I misread the bugzilla email on the bug that this is depending on 
Comment 24 Rex Dieter 2006-12-19 13:12:02 EST
Matthias, with the Packaging committee just passing:
http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
to use xdg-utils, this now becomes much less of an issue.

Heck, as far as I'm concerned, we can close this (unless you feel strongly
otherwise).
Comment 25 Matthias Clasen 2006-12-19 13:58:26 EST
With all due respect, thats crap.

xdg-icon-resource manages to wrap an 850 line shellscript around the very
same gtk-update-icon-cache call. 

And it still doesn't solve the "make it a cron job" issue...
Comment 26 Rex Dieter 2006-12-19 14:36:12 EST
Let's take the dialog to the mailing lists, this is no place for it.
Comment 27 Rex Dieter 2006-12-20 14:12:19 EST
updating summary, since it's clear any cron-based solution is probably not
acceptable.
Comment 28 David Zeuthen 2006-12-20 17:14:05 EST
Hi Rex. Regarding comment 24, I'm not sure the Package Committee should make
rules that forces package maintainers to use xdg-utils without understanding
what the implications are.

Matthias already told you in comment 15 how to solve this and Matthias is pretty
smart man so I would suggest to listen to him. And whether that post-transaction
hook invokes gtk-update-icon-cache or some Portland crap, I really don't care.
The whole point is that it's *transparent* for packagers that the cache is
updated. Wouldn't that be a lot nicer?

I, for one, am not going to use xdg-utils in my packages despite how many
committees tell me that I need to. I have that power as a package maintainer. Sorry.

Am sorry if this comes across as a flame but enough is enough. Thanks.
Comment 29 Rex Dieter 2006-12-21 08:34:22 EST
David, at this point, I don't give a rat's ass about xdg-utils (as a matter of
fact, the PC guideline has been withdrawn).  And calling it crap helps no one.

After further investigation, it appears that %posttrans hooks have their own
shortcomings, and shouldn't relied on to address this (by itself anyway).

> The whole point is that it's *transparent* for packagers that the cache is
> updated

Thank you!  We agree!  Halleluia!  Packagers should not have to worry, it should
"just work", and that task would best done *here*, in gtk2 (who else should hav
to care about gtk2's icon cache anyway?).

Matthias no doubt is a smart man, but I do question the common sense of letting
this linger on for 14+ months (with no end in sight).  I offerred a working
solution in comment #9.  I don't care if it is not ideal, it's 1000X's better
than any handy-wavy unimplemented theoretically-better solution.

Now, back to task:
0.  Relying solely upon rpm scriptlet hooks to keep icon cache fresh is
problematic (and an unmitigated hassle for packagers).  Agree/disagree?
1.  gtk2 should include a %post scriptlet to (re)generate (possibly missing)
initial icon cache.  Agree/disagree?
2.  gtk2 should include some mechanism to keep cache's fresh?  Agree/disagree?
Comment 30 Havoc Pennington 2006-12-21 11:58:01 EST
Though I doubt it makes sense to block this bug on a grand unified scheme, a 
nice grand unified scheme might be a little daemon that watches directories and 
can run scripts if those directories change (probably with some delay or other 
feature to avoid running the script over and over). Most "systemwide cache" 
situations would seem to need a thing like that (prelink, icon cache, 
documentation search indexes, etc.) Doesn't seem like a nice setup for this 
would be all that much work.
Comment 31 Matthias Clasen 2006-12-21 12:18:06 EST
0. Agreed that it is annoying. Thats why this bug is open, after all
1. It could, but thats largely irrelevant in this context. It can work
   just fine without an icon cache, it is just slower
2. Disagreed. See 2., GTK+ can survive just fine without an uptodate
   icon cache, so there is no real need to jump through complicated hoops
   to make random gtk+ applications write to /usr/share.

Havoc proposed a nice general solution.
Comment 32 Warren Togami 2006-12-22 16:07:38 EST
cron is an absolutely horrible solution.

A daemon that monitors and knows when regeneration is needed is a decent idea.

Another option would be %post setting a 'needs regeneration' flag, and it
regenerates it only *ONCE* at the end of rpm's transactions.  Any way to do this?
Comment 33 Matthias Clasen 2006-12-23 01:57:53 EST
Here is a patch which add the --delay option to gtk-update-icon-cache that was
outlined earlier. When called like

gtk-update-icon-cache --delay 60 /usr/share/icons/hicolor

it will touch /usr/share/icons/hicolor and then wait in the background until no
icon theme directory has been touched for 60 seconds before updating the icon
caches. If it finds an already waiting instance, it will only touch hicolor and
then exit.

This is a bit of a compromise between the regeneration flag in %post and daemon
approaches. 

Sorry for the excessive size of the patch.
Comment 34 Matthias Clasen 2006-12-23 01:58:56 EST
Created attachment 144330 [details]
patch
Comment 35 Matthias Clasen 2006-12-23 10:09:58 EST
Next steps: m

- measuring the performance impact of this, both in terms of the number of times
  the icon caches get updated during a rpm transaction and in terms of the 
  time the transaction takes.
- some robustness fixes to the daemon code
- consider hiding the "if [ -x /usr/bin/gtk-update-icon-cache ];" uglyness in
  a little script that can live in a package that we can just require for %post.


Comment 36 Matthias Clasen 2006-12-27 23:07:50 EST
Created attachment 144436 [details]
more robust patch

Here is another iteration, which makes the pid file handling a bit more robust.
Comment 37 Matthias Clasen 2007-01-03 16:39:00 EST
I just learned about incron (http://incron.aiken.cz/)
Comment 38 Toshio Kuratomi 2007-01-03 17:10:04 EST
Hey Matthias, Havoc,

I'm guessing neither of you are on the fedora-packaging list as there weren't
any replies to this post by Jason Tibbets:
  https://www.redhat.com/archives/fedora-packaging/2006-December/msg00176.html

Basically, how do you deal with the case where an incron type daemon isn't
running when the package is installed.
Comment 39 David Zeuthen 2007-01-03 17:26:35 EST
In response to comment 37: Please, no, not yet another system-wide that is going
to delay boot up, eat up RAM and bump our system requirements to 512MB RAM. It's
bad enough as is... Thanks.
Comment 40 David Zeuthen 2007-01-03 17:26:52 EST
In response to comment 37: Please, no, not yet another system-wide daemon that
is going to delay boot up, eat up RAM and bump our system requirements to 512MB
RAM. It's bad enough as is... Thanks.
Comment 41 Matthias Clasen 2007-01-03 19:47:55 EST
Yes, I'm currently leaning towards the --delay option, now that I've already
implemented it... 

It just needs testing.
Comment 42 Rex Dieter 2007-01-04 09:07:03 EST
Re: comment #38
afaict, if using an incron-type solution, then the cache won't be updated until
it is installed and running.
Comment 43 Rex Dieter 2007-06-21 09:42:41 EDT
Is the aforementioned patch (comment #36) integrated anywhere so that interested
folks can start testing it out?
Comment 44 Matthias Clasen 2007-10-10 14:37:14 EDT
Not going to make any changes here for F8
Comment 45 Dennis Gilmore 2008-01-22 09:29:57 EST
ping
Comment 46 Rex Dieter 2008-03-21 10:46:44 EDT
ping indeed, any chance to test the --delay patch for f9, or are we looking at
f10 territory now?
Comment 47 Dennis Gilmore 2009-03-20 18:54:42 EDT
ping
Comment 48 Matthias Clasen 2009-03-21 11:56:30 EDT
I'm not working on this. Feel free to pick it up...
Comment 49 Rex Dieter 2012-06-21 10:36:20 EDT
No need to keep this open forever, I can live with the status quo, and our currently fairly-optimized rpm scriptlets