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
Attachment:
pgp1aKQHx2uZQ.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
