Enrico Scholz wrote:
rdieter@xxxxxxxxxxxx (Rex Dieter) writes:
Why the 'touch' stuff?
The fdo spec mandates the timestamp of the installed-to icon dir
*must* be updated.
What is a 'fdo spec'?
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#implementation_notes
Oh, I see. The 'touch' makes a differences when user installed a 3rd party
application with a 3rd party toolkit which is following freedesktop.org
iconcache-recommendations.
Take 3rd party of it. This includes *all* apps using *any* toolkit.
| gtk-update-icon-cache --quiet --force %{_datadir}/icons/hicolor || :
vs.
| touch --no-create %{_datadir}/icons/hicolor || :
| %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || :
would led to your conclusion.
Consider the case that gtk2 (and gtk-update-icon-cache) is not present at
install-time (since we currently don't Requires(post,postun): gtk2),
Please don't write 'Requires(post,postun):'; dunno whether you meant it
symbolically only. But it's wrong and sickly.
It's simply shorter than writing (the more proper and working):
Requires(post): gtk2
Requires(postun): gtk2
then the icondir timestamp will fail to be updated.
This would not make a difference: in both cases ('touch' and '--force')
the iconcache will be updated in the same manner during the installation
of 'gtk-update-icon-cache'.
OK, I'll say it one more time: Lacking
Requires(post): gtk2
Requires(postun): gtk2
*gtk2 may not be present at install-time*. As such,
gtk-update-icon-cache present in scriplets may not get run, thus, the
icondir timestamp may not get updated.
Am I missing something?
Currently (with FC5 gtk2), icon-cache won't be updated because gtk2's
scriptlets do not call 'gtk-update-icon-cache'.
Neither does *any* gtk2 release, for that matter. That's related to the
gtk2 bug, that our currently scriplets are covering up. I'm concerned
that the bug will never get fixed or get the attention it deserves if
the bandaid is never (threatened to be) removed.
-- Rex
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
