On Sunday 22 February 2009, Enrico Scholz wrote:
> Ville Skyttä <ville.skytta@xxxxxx> writes:
> > %postun
> > if [ $1 -eq 0 ] ; then
> > touch --no-create %{_datadir}/icons/hicolor &>/dev/null
> > gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
> > fi
>
> The 'touch' should be inconditional and outside of the 'if' block.
> E.g. when we have a transaction like
>
>
> 1. UPDATE new1
> 2. UPDATE old
> 3. UPDATE new0
> 4. ERASE new0
> 5. ERASE old
> 6. ERASE new1
> 7. %posttrans
>
>
> where newX have the scriptlet above and 'old' has a legacy scriptlet
> which executes 'gtk-update-icon-cache' everytime. Then, 'old' will
> update the cache in step 5 and %posttrans will be a noop. Changes in
> step 6 will be ignored and system has the cache from step 5.
What practical problems would that cause? The resulting icon cache could
contain entries for icons that were removed in step 6, but that'd only affect
scenarios where the old version of new1 in the above had icons that the new
version of new1 didn't have which I bet is a very rare case and it isn't
obvious to me where this would be an actual problem because references to
those icons have almost certainly gone away updated desktop files shipped
with the new version of new1, or will go away along with the old version of
new1 if it contained desktop files that the new new1 doesn't have.
Updating the timestamp of the toplevel icon dir more often than necessary
would probably cause environments that auto-update their caches or the like
based on the timestamp ending up doing it more often than necessary.
Unless I missed something crucial, IMO this (theoretical?) problem should be
just ignored, packagers should start updating their cache update scriptlets
to the ones in the Wiki draft at their earliest convenience and it isn't
necessary to carry around legacy cruft.
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
