[Fedora-packaging] Re: Re: Re: iconcache scriptlets

[Rex Dieter]

Enrico Scholz wrote:

> rdieter at math.unl.edu (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.
> 
> Does gtk1, QT or wxWindows implement the freedesktop icon caching?

kde does, the others, dunno, but imo, doesn't matter.  Fact is, any toolkit
*could* implement caching, and the standard mandates that in order for any
caching implementation to work, the timestamp must be updated.

I hope you're not suggesting that it be ok to purposely not follow the
standard.

>>>> 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?
> 
> yes; the timestamp itself is important for gtk (and other toolkits
> following the freedesktop recommendations) only. 

Of course, that's a given.

> Not touching the 
> timestamp would cause only currently running 3rd party apps (using
> such a toolkit) not to recognize the new icons.

Wrong, it would (ok, could, depending on imlementation) cause any app
(currently running or not), using any toolkit (that supports the fdo) spec
to not recognize the new icons.

-- Rex