[Pkg-ime-devel] Bug#746968: ibus-array should be removed

Keng-Yu Lin kengyu at lexical.tw
Sun May 4 18:26:44 UTC 2014

As an Array 30 IM user, the ibus-table-array30 package did not
implement the full features of the Array 30 IME (such as no quick
codes, no first and second class simple codes) where ibus-array
implemented these extra features.

Also as the package maintainer of ibus-array package, I am happy and
will spend some time looking at the ibus-python issue.

2014-05-04 20:49 GMT+08:00 Osamu Aoki <osamu at debian.org>:
> Source: ibus-array
> Version: 0.0.2-9
> Severity: normal
> In short, we should remove this ibus-array package.
> The reason is that ibus-array is one of the few packages which still
> uses ibus-python interface which is about to be removed from ibus(*).
>  * ibus-array           popcon=ca. 30 (uses ibus-python)
>  * ibus-table-array30   popcon=ca. 30 (does not use ibus-python)
> Since the ibus-table-array30 binary package which is generated from the
> ibus-table-chinese source package seems to support this particular
> array30 chinese input method, I see no major problem.  (I also see a low
> popcon value.)
> So question is what to do for wheezy.  3 options.
>  1) we just remove ibus-array. (My choice)
>  2) we upload transition package of ibus-array depending on
>     ibus-table-array30.
>  3) we modify ibus-table-array30 to provide ibus-array.
>    (need ibus-table-chinese source package upload)
> Unless I get specific request/help/... , I will just do option 1 to
> remove this ibus-array.  Objection?
> Let me know your thought by replying to this Debian bug report.  Once we
> decide on this, I can work on other 3 packages which are affected.
>  * ibus-pinyin       popcon=443
>    ibus-pinyin needs to update its package dependency so it can be
>    removed from this list.  I will handle this separately.
>  * ibus-googlepinyin popcon=330
>    Considering other newer pinyin methods are available, simply removing
>    this should be OK just like ibus-array.
>  * ibus-el           popcon=103
>    Whoever uses this with EMACS should consider using uim instead since
>    they can stay within LISP world using uim bindings of IM.
> Regards,
> Osamu
> (*) ibus-python removal background.
>     The upstream does not actively support ibus-python and has been
>     recommending to move to use Gobject introspection.  So continuing to
>     ship unsupported zombie ibus-python code just because its old code has
>     not been removed is not good idea.
>     Since most of the IM packages completed this transition, I am planning
>     to remove ibus-python.
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> -- no debconf information

More information about the Pkg-ime-devel mailing list