On Thu, May 27, 2010 at 10:17:10AM -0400, Matthias Clasen wrote:
This cycle, some things land in GNOME land that will require minor
adjustments of scriptlets:
1) GIO modules. GIO now uses a caching approach to its modules. If a
package installs a loadable module in %{_libdir}/gio/modules, you need
to run gio-querymodules to update
%{_libdir}/gio/modules/giomodule.cache. There's the usual multilib pain;
glib2 installs the binary as gio-querymodules-32/64. I propose to
recommend the following scriptlets for this:
%posttrans
gio-querymodules-%{__isa_bits} || :
%postun
gio-querymodules-%{__isa_bits} || :
2) GSettings. GConf is on the way out, we will start seeing applications
that are ported to GSettings (which is part of libgio in the glib2
package). GSettings uses schemas as well, and has a cache of those that
needs updating if schemas are added/removed. The tool for this is
glib-compile-schemas (schemas and their cache are arch-neutral, so no
multilib pain here). Proposed scriptlets:
%posttrans
glib-compile-schemas %{_datadir}/glib-2.0/schemas || :
%postun
glib-compile-schemas %{_datadir}/glib-2.0/schemas || :
3) GTK3. gtk3 will be parallel installable with gtk2, which means it
keeps its loadable modules separate. I took the occasion to rework
things a bit to reduce the multilib pain. gdk-pixbuf loaders, theme
engines and im modules get installed to
%{_libdir}/gtk-3.0/3.0.0/{loaders,engines,immodules}, and the cache
files for loaders and immodules have been relocated to
%{_libdir}/gtk-3.0/3.0.0/{loaders,immodules}.cache. Suitable scriptlets
to update these caches look as follows:
%posttrans
gdk-pixbuf-query-loaders-3.0-%{__isa_bits} --update-cache || :
gtk-query-immodules-3.0-%{__isa_bits} --update-cache || :
%postun
gdk-pixbuf-query-loaders-3.0-%{__isa_bits} --update-cache || :
gtk-query-immodules-3.0-%{__isa_bits} --update-cache || :
I guess all the %postun scriptlets could be optimized with a if $1 -eq 0
#2 was passed yesterday by FPC based on a combination of your messade to
devel list and rhughes message here. I need to write it into draft form
before handing it over to fesco.
If you could write up #1 and #3 in draft form (basically, something that we
can drop in verbatim into the ScriptletSnippets page) that would help out
a lot as I'm able to keep up otherwise.
I need to write up a bit about the pitfalls to watch out for with using
%posttrans in these transactions which makes writing up the initial
%GSettings one a tad more difficult.
Some things that should be made clear:
* What package is the relevant command line tool provided in? Is a package
that invokes the command line tool ever lkely to not require the package
that provides the command line tool implicitly?
* What happens if the command line tool is not available at scriptlet time?
Does it break? Does the command line tool get run by the %posttrans
script of the package that provides it?
* Are there any command line tools that depend on another one of these
"services". As a hypothetical: if gtk-query-immodules-3.0-%{__isa_bits}
required a GSettings schema, we'd want to note something like:
"GSettings cannot always be run in %posttrans. For instance, package Foo
that provides gtk-query-immodules-3.0-%{__isa_bits} must run it in %post
to prevent stale schemas from potentially breaking
gtk-query-immodules-3.0-%{__isa_bits} when that package is run from
another %post script"
Thanks,
-Toshio