Bug#343605: libgtk2.0-bin: apiver should contain the arch-os-gnu triplet

[Loïc Minier]

        Hi Goswin,

 Please find below a short summary of the pango1.0 multiarch changes and
 and a preview of the Gtk implementation.

On Fri, Dec 16, 2005, Goswin Brederlow wrote:
> while working on multiarch support I notice that gtk2.0-bin will
> break. In update-gtk-immodules you set 'apiver=2.0' and create
> /etc/gtk-$apiver/gtk.immodules. For multiarch systems there must be
> multiple such files, one for each abi used.

 I've worked on multiarch support in pango1.0, and I've just uploaded a
 first version to unstable, but with a relatively different approach.

 With modules, these are the main problems:
 - location of the actual modules
 - content and/or location of files listing modules

 The first one is relatively easy to solve with configure's --libdir, so
 let's tackle the other problem.

 Pango only loads modules from absolute pathes.  The default module path
 is LIBDIR/pango/MODVER/modules.  The list of modules to load is
 configurable, and is SYSCONFDIR/pango/pango.modules by default.

 What I did for Pango was to alter the module loading code to load all
 modules listed in all files matching
 LIBDIR/pango/MODVER/module-files.d/*.modules (plus
 SYSCONFDIR/pango/pango.modules for compatibility).  Each binary package
 has to generate such a file which lists absolute pathnames, and this
 can be achieved via dh_pangomodules.


 Now this was not too complicated for Pango because it only loads
 modules listed in the files listing pango modules absolute pathnames
 and because there's only one module type.
   The only other package shipping Pango modules (pango-libthai) was
 converted to this new layout and is in unstable since 5 days.


 Enter Gtk, which has 6 module types (filesystem backends, gdkpixbuf
 loaders, engines, input methods, and printing backends, as well as
 generic "modules").

 It seems to me that only gdkpixbuf loaders and immodules are listed in
 configurables files.  These list only absolute pathnames (relative ones
 are supported, but no prefix is prepended, so this is useless for us or
 would need patching).

 Other modules types do not have a query tool to generate a
 configuration file listing them, and they seem to all be loaded when
 requested (by programs, config file, or environment vars), and not
 automatically.

 So, I basically did the same thing than for Pango, but with two sets of
 module files.

 (I didn't enable Multiarch LIBDIR switching in Gtk yet, as it is
 impractical to do until all modules have been converted to the new
 module handling mechanism.)


 Finally, there's a special virtual provide to track the binary version
 of modules.  This virtual provides has the multiarch keyword in it for
 a dh_pangomodules built with multiarch support, so it should prevent
 from mixing non-multiarch modules with multiarch pango and vice-versa.

 I would appreciate your feedback on version 1.14.5-1 built with
 DEB_BUILD_OPTIONS=multiarch.

 I've rebuilt 1.14.5-1 with DEB_BUILD_OPTIONS=multiarch as
 1.14.5-1multiarch1, and it's available at:
<http://people.dooz.org/~lool/debian/pango1.0/1.14.5-1multiarch1/experimental/>

   Bye,
-- 
Loïc Minier <lool at dooz.org>