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)

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.

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 ;))

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...

>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.

Hmm, we probably never added it back to the spec.

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.

Retargeting devel, let's see if this can make fc6.

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.  (:

ping, pretty please with sugar on top, can this make fc6?

+1

Unfortunately, it didn't...

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?

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

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.

> 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.  

(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)?

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

> 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...

and this is not a bug why ?

You are barking up the wrong tree. This is bug is not NOTABUG

hee.  "This bug is not NOTABUG", say that 10 times fast.

Sorry Matthias,  

I misread the bugzilla email on the bug that this is depending on 

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).

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...

Let's take the dialog to the mailing lists, this is no place for it.

updating summary, since it's clear any cron-based solution is probably not
acceptable.

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.

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?

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.

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.

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?

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.

Created attachment 144330 [details]
patch

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.

Created attachment 144436 [details]
more robust patch

Here is another iteration, which makes the pid file handling a bit more robust.

I just learned about incron (http://incron.aiken.cz/)

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.

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.

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.

Yes, I'm currently leaning towards the --delay option, now that I've already
implemented it... 

It just needs testing.

Re: comment #38
afaict, if using an incron-type solution, then the cache won't be updated until
it is installed and running.

Is the aforementioned patch (comment #36) integrated anywhere so that interested
folks can start testing it out?

Not going to make any changes here for F8

ping

ping indeed, any chance to test the --delay patch for f9, or are we looking at
f10 territory now?

ping

I'm not working on this. Feel free to pick it up...

No need to keep this open forever, I can live with the status quo, and our currently fairly-optimized rpm scriptlets