To confirm my claim below, I talked to m17n-lib upstream author. And it is confirmed, thus, I changed subject of this mail.
2010-05-29 23:49, NIIBE Yutaka wrote: > It seems for me that the real problem is in the packaging of libm17n-0. [...] > (1) emacs23 package depends on libm17n-0 package, because GNU Emacs > executable is linked to the libraries of libm17n-0 package, > specifically, libm17n-flt.so.0 and libm17n-core.so.0. > > (2) The libm17n-0 package includes libm17n-flt.so.0 and > libm17n-core.so.0, as well as libmimx-anthy.so.0. > > (3) The libm17n-0 package depends on libanthy0 package, because > libmimx-anthy.so.0 in libm17n-0 package is linked to libanthy.so.0 and > libanthydic.so.0, which are in libanthy0 package. > > (4) In any sense, there are no executable or libraries in emacs23 package > which require something in libanthy0 package (directly or indirectly). libmimx-anthy.so.0 is a plugin of m17n-lib loaded by libm17n.so.0, when users use japanese-anthy input method. (Currently it has soname, which is confusing, but upstream CVS version fixed this already.) In m17n-db package, there is a file /usr/share/m17n/ja-anthy.mim, this defines module (plugin) needed, that's libmimx-anthy.so.0. Situation is same for libmimx-ispell. So, the solution for this problem is not packaging of anthy, but fine grain packaging of m17n-lib (libm17n-0, m17n-db, and others). The only program which use /usr/share/m17n/ja-anthy.mim and libmimx-anthy.so.0 is m17n-edit. This is basically demonstration program of m17n-lib, not intended for real use. I think that m17n-lib packaging should have separate plugins packages for anthy and ispell, or plugins should be in m17n-lib-bin package. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
