ScriptletSnippets: desktop-database,mimeinfo

Ville Skyttä ville.skytta at iki.fi
Sun Feb 5 11:13:20 UTC 2006


On Fri, 2006-02-03 at 21:03 -0600, Rex Dieter wrote:
> Enrico Scholz wrote:
> 
> > There is a difference between Requires(post): and a plain Requires:. The
> > first statement guarantees that the cache will be created, the latter
> > might miss to create it.
> 
> Not if gtk2 run gtk-update-icon-cache in its own %post.  (-:

In the case of 1) an app that already requires gtk2 eg. through a shared
lib dependency, and 2) assuming no dependency loops involving both gtk2
and the package are present (which is pretty much granted in Extras) and
3) that the cache updater executable is assumed to be in the gtk2
package, I fail to see how the app could be installed before gtk2 -> the
Requires(post) and gtk2 running gtk-update-icon-cache in its %post are
no-ops in the scope of this particular problem (and actually, I think
the problem does not exist).

If 1) above doesn't hold true, the %trigger approach would be "correct"
but it has its drawbacks.

If you have evidence suggesting otherwise, please post it somewhere for
examination.

On the other hand, I seem to remember that some recent versions of rpm
have added a %posttrans scriptlet which (if it indeed exists and does
what I think, never tried it) could be used solve this problem cleanly
in packages, without %triggers or any Requires, using the "|| :" or
test-if-executable-exists-before-invoking-it safeguards.

Does something benefit from updating the GTK icon cache (or require it)
for a non-GTK app?  If so, in addition to using %posttrans, the gtk2
package would need to run the cache updater in its %post.

Is it just me or do others think that GNOME/GTK has some catching up to
do in this area when compared to KDE's "it just works" implementation?
Unfortunately the trend seems to be that GNOME/GTK is drifting further
away from "just works", with the amount of additional required
whatever-updated executables to run increasing...




More information about the fedora-extras-list mailing list