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 <[EMAIL PROTECTED]>
