gtk-update-icon-cache %posttrans (was Re: Error output from rpm pre/post scripts)
Matthias Clasen
mclasen at redhat.com
Fri Jul 6 13:33:00 UTC 2007
On Fri, 2007-07-06 at 07:27 -0500, Rex Dieter wrote:
> Toshio Kuratomi wrote:
>
> > On Thu, 2007-07-05 at 16:15 -0400, Matthias Clasen wrote:
>
> >> Now that we are discussing this again, I'd like to point out that the
> >> recent ldconfig/%posttrans discussion is somewhat related to this. If
> >> we can make %posttrans useful for ldconfig, we can use it for icon cache
> >> updates too. That would be a big win.
> >>
> > That would be great. Unfortunately, %posttrans doesn't work in the
> > ldconfig case because it doesn't run when only erasing packages. Will
> > that make a difference for gtk-update-icon-cache as well?
>
> use %postun to handle the uninstall case (at least until when/if
> rpm %posttrans behaves better here):
>
> %posttrans
> touch --no-create %{_datadir}/icons/hicolor ||:
> gtk-update-icon-cache -q %{_datadir}/icons/hicolor 2> /dev/null ||:
>
> %postun
> if [ $1 -eq 0 ]; then
> touch --no-create %{_datadir}/icons/hicolor ||:
> gtk-update-icon-cache -q %{_datadir}/icons/hicolor 2> /dev/null ||:
> fi
>
That would work, but do we really want to change all the affected specs
again, when a fixed %posttrans/%postuntrans becomes available ? Has
there been any response from rpm maintainers as to the feasibility and
time-frame for a fixed %posttrans/%postuntrans ?
Note that even when pushing things to %posttrans, you get a ton of
invokations, so %posttrans only helps for tools which are "idempotent".
Thankfully, gtk-update-icon-cache is.
More information about the Fedora-maintainers
mailing list