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