[Fedora-packaging] Re: Suggested ScriptletSnippets (=?iso-8859-1?q?icon=09cache?=) changes

Ville Skyttä ville.skytta at iki.fi
Sun Feb 22 17:09:34 UTC 2009


On Sunday 22 February 2009, Enrico Scholz wrote:
> Ville Skyttä <ville.skytta at iki.fi> 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.




More information about the Fedora-packaging mailing list