Debian Bug report logs - #582830
libanthy0: The dependency on anthy-common pulls in 13 MB

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@stusta.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libanthy0: The dependency on anthy-common pulls in 13 MB

Date: Mon, 24 May 2010 02:28:32 +0300

Package: libanthy0
Version: 9100h-6
Severity: normal

I don't have any knowledge of Japanese, and the only reason why I have
libanthy0 installed is that it is a dependency of emacs23 (through libm17n-0).

The new dependency on anthy-common pulls in 13 MB, and that's a bit heavy
for something I am not interested in at all but forced to install.

Message #10 received at 582830@bugs.debian.org (full text, mbox, reply):

From: NIIBE Yutaka <gniibe@fsij.org>

To: 582830@bugs.debian.org

Subject: Isn't it the issue of libm17n-0 packaging?

Date: Sat, 29 May 2010 23:49:10 +0900

It seems for me that the real problem is in the packaging of libm17n-0.
It completely makes sence libanthy0 depends on anthy-common, because
libanthy0 *always* use the dictionary.

I figure out following relationships.

(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).


If libm17n-0 package were fine grained and just included its core
features of libm17n-flt.so.0 and libm17n-core.so.0, and not included
libmimx-anthy.so.0, emacs23 package wouldn't depends on (indirectly)
libanthy0 and anthy-common.

If you agree, please reassign this bug report to libm17n-0.
-- 

Message #19 received at 582830@bugs.debian.org (full text, mbox, reply):

From: NIIBE Yutaka <gniibe@fsij.org>

To: 582830@bugs.debian.org

Subject: This is the issue of m17n-lib packaging

Date: Wed, 09 Jun 2010 12:14:50 +0900

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.
-- 

Send a report that this bug log contains spam.