[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

GTK+ input module packaging



Hi GTK+ package maintainers,

[Please cc: me as I'm not subscribed (yet)]

I am one of the maintainers of package scim, a input method platform
mainly for CJK languages (it's called a platform because it supports
various imput methods).  Scim provides GTK+ IM modules, and we have a
separate binary package scim-gtk2-immodule for this feature.  However I
have a problem in packaging.

>From my understanding, in order to make a GTK+ IM module work, it needs
to be registered in /etc/gtk-2.0/gtk.immodules.  And
/usr/bin/gtk-query-immodules-2.0 is used to generate the list of
registered IM modules.  However in Debian, package libgtk2.0-bin
provides a wrapper /usr/sbin/update-gtk-immodules, and libgtk2.0-bin
calls this script in postinst.

However this script only searches the IM modules (im-*.so files) in
/usr/lib/gtk-2.0/2.4.0/immodules, so our package faces a tough choice --
either install the modules in /usr/lib/gtk-2.0/2.4.0/immodules, and have
it break every time GTK+ bumps minor version; or install them in
/usr/lib/gtk-2.0/immodules, and figure out some way to make sure scim is
still usable after a libgtk2.0-bin upgrade.

Right now I am going with the first option, since I really don't know
how to make sure im-scim.so is registered after a libgtk2.0-bin upgrade.
Now I install the module im-scim.so in /usr/lib/gtk-2.0/2.4.0/immodules,
and call /usr/sbin/update-gtk-immodules in scim-gtk2-immodule's postinst
and postrm.

The problem of the current setting is that it will be broken when GTK+
upgrades to 2.6.  So should I at least conflict with libgtk2.0-0 (>>
2.5.0)?  (By the way, just curious, why are the IM modules
/usr/lib/gtk-2.0/2.4.0/immodules/im-*.so are included in libgtk2.0-0
package, but /usr/sbin/update-gtk-immodules are called in
libgtk2.0-bin's postinst?)

The upstream installs the module in /usr/lib/gtk-2.0/immodules, and
actually /usr/bin/gtk-query-immodules-2.0 searches
/usr/lib/gtk-2.0/immodules by default (and put a path list in it's
output, which is supposed to become /etc/gtk-2.0/gtk.immodules) so it is
probably not a problem for other distributions.

It would be nice if there is a better way to solve this so that we don't
need to patch and re-upload after each GTK+ minor version upgrade
(though currently scim updates faster than GTK+, so not a big problem).
I may misunderstood the situation here, or missed something obvious.  So
any comments or pointers would be appreciated.

Regards,
Ming
2005.01.27



Reply to: