gtk-update-icon-cache %posttrans (was Re: Error output from rpm pre/post scripts)

[Matthias Clasen]

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.