Hello,
I'd suggest the following changes to the "GTK+ icon cache" entry in
Packaging:ScriptletSnippets:
1) Rename the entry to "Icon cache". It's not all about GTK+ but KDE as well.
2) Append " &>/dev/null" to the "touch" line in %postun. If "touch" is not
available when the package is removed, I find it more than likely that GTK+
or KDE are not there to benefit from icon cache updates any longer
either. /usr/share may also be mounted read only with %_netsharedpath.
3) Append " &>/dev/null" to the "touch" line in %post. If "touch" is not yet
available, neither should be kdelibs, and thus there is no reason to touch
the dir. kdelibs itself does a forced update in its %post. /usr/share may
also be mounted read only with %_netsharedpath. (This avoids the need to add
unnecessary "Requires(post): coreutils" to every package that installs icons
just to quiet down a pretty rare and harmless warning.)
4) Remove the -x test and --quiet option to gtk-update-icon-cache, redirect
all output (including stderr) to /dev/null. gtk-update-icon-cache may not be
installed, /usr/share may be mounted read only with %_netsharedpath, etc...
and the --quiet tells me that there was no interest in seeing g-u-i-c's
stdout anyway.
5) Wrap %post in "if [ $1 -eq 1 ] ; then ..." to take care of the initial
installation and let %postun handle package upgrade cases in order to
eliminate one touch and one g-u-i-c invocation per package upgrade. I
suppose this would be "safe enough" to do, it'd just result in possibly stale
icon caches for the duration of the upgrade transaction. (Icons change
relatively rarely, and even if they do, does this smallish stale cache window
really matter at all?)
So the scriptlets would become:
%post
if [ $1 -eq 1 ] ; then
touch --no-create %{_datadir}/icons/hicolor &>/dev/null
gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
fi
%postun
touch --no-create %{_datadir}/icons/hicolor &>/dev/null
gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
