On Wed, 2005-04-06 at 20:24 +0200, Jacob Kroon wrote: > Jacob Kroon wrote: > > > When not using the -f flag it seems to me, that if the cache file > > already is "up2date", > > or rather "ok", it doesnt get an updated time-stamp, even if the > > directory is older > > than the cache-file. > > > > Possible scenario: > > A new redhat-artwork rpm is released which contains a small fix, > > resulting in that > > fixing the cache is unneccesary. The directories timestamp is > > increased, so the icon-cache > > gets outdated, the %post script runs but since the small fix didn't > > require a rebuild > > of the cache, and because of this "possible" bug, it's left as is. > > I have verified this on my system at least: > > rpm -q redhat-artwork > redhat-artwork-0.122-1 > > Steps to reproduce: > > 1. touch /usr/share/icons/Bluecurve > 2. Run postinstall script for redhat-artwork > > for dir in /usr/share/icons/*; do > if test -d "$dir"; then > /usr/bin/gtk-update-icon-cache --quiet $dir > fi > done > > 3. Check timestamps for /usr/share/icons/Bluecurve and > /usr/share/icons/Bluecurve/icon-theme.cache > > The icon-cache file is older than the directory... 8( > > Should I bugzilla this, and in that case to which component ? I'm not > quite sure how gtk-update-icon-cache is supposed > to behave, but from what I've heard the --force flag shouldn't be > necessary, the script should fix it, and in that case > gtk-update-icon-cache is the problem. > > /Jacob > File it upstream against gtk+ in bugzilla.gnome.org, please. Thanks, Matthias