Hi Goswin,
Please find below a short summary of the pango1.0 multiarch changes and
and a preview of the Gtk implementation.
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,