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