Bug#651075: imhangul-common: wrong way to use im-config, wrong dependency, ...

[Osamu Aoki <osamu@debian.org>]

Hi,

On Tue, Dec 06, 2011 at 11:46:41AM +0900, Changwoo Ryu wrote:
> 2011-12-06 (화), 00:22 +0900, Osamu Aoki:
> > Package: imhangul-common
> > Version: 1
> > Severity: normal
> > 
> > This package ships im-config related package.  That is wrong.  Please
> > send patch to im-config package (if needed NMU carefully).
> > 
> > Any undocumented way of usage is prone for problem.
> > 
> > In new 0.6, I added support for imhangul and other related packages.
> > (Besides internal configuration file names and code has changed
> > significantly...)
> 
> Should im-config have all required configurations of the input methods
> packages in Debian, rather than registering themselves by input methods?

Yes.

> Then I think it is a wrong design choice. 

I understand one can make a valid argument.  Since I may not be always
up to date with each IM's internals. But this was sure way to quickly
change from im-switch to im-config.  This was a practical solution step
at this moment for me.

The first step is having a working solution which ensures to have both
GTK2 and GTK3 installed before enabling them.  You can not do it
intuitively with im-switch.  Also this ensures quick adoption of
multiarch.

If you have time, please check 
  /usr/share/im-config/data/50_hangul.rc
to see what I did for Korean is right choice.  The code 

Oops, I have wrong comment text... 
 s/gtk-im-libthai/imhangul-gtk2 and imhangul-gtk3/

I hope this start-up code is much more natural than the over
engineered im-switch one.

The other reason of centrarized data is ease of transition.

Once we stabilize to be version 1.0, we can certainly discuss such idea.
I think we need to at least impliment gettext translation.

> Consistency in different packages will easily break.

Hmmmm... Actually, we had and still have quite a bit of mess on
*consistency* with im-switch.  Different subpackage owner places their
hook scripts and fight for the higher priority.  Also there are some
cross package interaction which makes it impossible to have linear
ordering.   (scim-pinyin and scim having hook script in each may have
been the case I thought to be bad.)

Managing such case was needed and instead of having many such -common
packages, I made this to be a single point.
 
> But if it is the current design, please NMU.

OK.

Osamu