redhat-artwork postinstall script

Matthias Clasen mclasen at redhat.com
Wed Apr 6 19:10:48 UTC 2005


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




More information about the fedora-test-list mailing list