5:53 a.m.
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
--
Best Regards
Marcin Garski
10:21 p.m.
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
11:37 a.m.
On 9/23/06, Rex Dieter <rdieter(a)math.unl.edu> 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.
4:51 p.m.
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
6:56 a.m.
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
8:36 a.m.
OK, comments?
http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache
-- Rex
6415
days inactive
6418
days old
packaging@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
Christopher Stone -
Marcin Garski -
Rex Dieter