[Fedora-packaging] Packaging-related changes in GNOME

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20100527/3f2fae3d/attachment.bin