GTK+ icon cache "bugs" on ScriptletSnippets

[Marcin Garski]

Hello,

I'm a maintainer of Krusader package in Fedora Extras. Recently I've 
recived bug report http://bugzilla.redhat.com/206650

yum install krusader

Installing: krusader                     ######################### [1/1]
No theme index file in '/usr/share/icons/locolor'.
If you really want to create an icon cache here, use --ignore-theme-index.

I've started to investigate it. The problem is GTK+ icon cache. I've 
used in my spec file scripts from:
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets (GTK+ icon 
cache section).
This scripts doesn't check if %{_datadir}/icons/hicolor/index.theme 
exist, so in this case gtk-update-icon-cache generate such error.
My proposed resolution for this bug can be found in 
http://bugzilla.redhat.com/206860 but I will also paste it here:

if [ -x %{_bindir}/gtk-update-icon-cache ]; then
         if [ -f %{_datadir}/icons/hicolor/index.theme ]; then
                 touch --no-create %{_datadir}/icons/hicolor || :
                 %{_bindir}/gtk-update-icon-cache --quiet
%{_datadir}/icons/hicolor || :
         fi
fi

[Rex Dieter]

Marcin Garski wrote:
> My proposed resolution for this bug can be found in
> http://bugzilla.redhat.com/206860 but I will also paste it here:
>
> if [ -x %{_bindir}/gtk-update-icon-cache ]; then
>         if [ -f %{_datadir}/icons/hicolor/index.theme ]; then
>                 touch --no-create %{_datadir}/icons/hicolor || :
>                 %{_bindir}/gtk-update-icon-cache --quiet
> %{_datadir}/icons/hicolor || :
>         fi
> fi

I'd argue to greatly simplify the above to just:
gtk-update-icon-cache -q %{_datadir}/icons/hicolor 2>/dev/null ||:
but that's just me.

Actually, I'd argue this, imo, *stooopid* gtk-update-* crud doesn't
belong in packages at all, but again, that's just me, or wait, me and
*lots* of others too:
http://bugzilla.redhat.com//170335

-- Rex

[Christopher Stone]

On 9/23/06, Rex Dieter  wrote:
> Marcin Garski wrote:
> > My proposed resolution for this bug can be found in
> > http://bugzilla.redhat.com/206860 but I will also paste it here:
> >
> > if [ -x %{_bindir}/gtk-update-icon-cache ]; then
> >         if [ -f %{_datadir}/icons/hicolor/index.theme ]; then
> >                 touch --no-create %{_datadir}/icons/hicolor || :
> >                 %{_bindir}/gtk-update-icon-cache --quiet
> > %{_datadir}/icons/hicolor || :
> >         fi
> > fi
>
> I'd argue to greatly simplify the above to just:
> gtk-update-icon-cache -q %{_datadir}/icons/hicolor 2>/dev/null ||:
> but that's just me.
>
> Actually, I'd argue this, imo, *stooopid* gtk-update-* crud doesn't
> belong in packages at all, but again, that's just me, or wait, me and
> *lots* of others too:
> http://bugzilla.redhat.com//170335

+1 on stupidity comment.  Just curious, how come KDE doesn't have to
do such stupid things?

Let's please remove gtk+ stupidity from spec files.

Thanks.

[Rex Dieter]

Christopher Stone wrote:
> Just curious, how come KDE doesn't have to
> do such stupid things?

kde doesn't cache icon themes.  To be fair, gtk doesn't *have* to
redo/use gtk-update-icon-cache either, as it will (properly) fall-back
to not using the cache if it is stale (and it'll just be slower, of course).

-- rex

[Rex Dieter]

Rex Dieter wrote:
> Christopher Stone wrote:
> > Just curious, how come KDE doesn't have to
> > do such stupid things?
>
> kde doesn't cache icon themes.  To be fair, gtk doesn't *have* to
> redo/use gtk-update-icon-cache either, as it will (properly) fall-back
> to not using the cache if it is stale (and it'll just be slower, of
> course).

OK, one more cause to take up with the packaging committee.  We should just
get the guideline fixed properly once and for all, and leave the gtk2
maintainer to the job of fixing the bug (that's really what we have here, a
workaround for a hack/bug).

-- Rex

[Rex Dieter]

OK, comments?

http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache

-- Rex