On Wed, 2006-11-01 at 07:11 -0600, Rex Dieter wrote: > Patrick W. Barnes wrote: > > Can we get this reviewed and, if appropriate, fixed on the wiki? > > > > http://bugzilla.redhat.com/206860 > > > > I honestly don't care if there's a better solution forthcoming, but as long as > > this information is provided on the wiki, it should be as accurate as > > possible. > > Until something better does come along(*), imo, the simplest workaround > is to simply ignore gtk-update-icon-cache's output, and use something like: > > %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor > 2>/dev/null || : > icons/hicolor isn't a problem. hicolor-icon-theme owns that directory and includes an index.theme file so there is no warning. Similarly with the theme directories owned by kdelibs, gnome-themes, gnome-themes-extras, and redhat-artwork. But no one owns icons/locolor and provides an index.theme file. This ownership of the directory and index.theme should be fixed to fix this bug. (Side note: all of the %{_datadir}/icons hierarchy needs some ownership and Requires: cleanup.) Options: * From my reading of the f.d.o spec[1]_ krusader should be installing into hicolor instead of locolor. Since hicolor is the fallback theme and krusader doesn't install anything there, krusader will end up without an icon if the user selects a theme without a krusader icon. This might be a misunderstanding of the name "hicolor" -- it's just a theme name it doesn't imply that there's a framework to select hicolor, locolor, monochrome, and b/w icons depending on usage. * locolor-icon-theme package similar to hicolor-icon-theme. * Some other package owns icons/locolor and provides index.theme. Changing ScriptletSnippets would only be a kludge but there are several options there: 1) When installing to icons/locolor on FC7 or less use the --ignore-theme-index switch to gtk-update-icon-cache. 2) When installing to icons/locolor on FC7 or less, do not use this scriptlet. 3) Do not install any files into icons/locolor. If your app is doing so it is likely doing the wrong thing. [1]_:http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html > > (*) > http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache > I'm sorry I missed the initial announcement of this. I think your revisions make sense after xdg-utils go into Core and the requirement tree for gtk2 is in place (hicolor-icon-theme should work fine for this). Changing the guidelines before that would break things that currently work. (Or we could place a hard Require:s on xdg-utils until it was fixed.) Is there an RFE open to get xdg-utils into Core and make the necessary changes? If the relevant maintainers think it's a good change we can mention that the suggested scriptlet is changing in FCX. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
