uim: disable non-utf-8 anthy backend

[Gorggg]

After the recent upgrade of anthy to 0.4 in 700c492, the anthy input method in uim will no longer work with the anthy available in the repository, instead requiring the anthy-utf8 input method to interface and convert kanji correctly. In order to prevent broken configurations, this change disables the build of the old anthy input method.

In order to avoid installing the new build of uim-anthy when the old anthy is present, I set uim-anthy to conflict with older versions of anthy that use EUC-JP instead of UTF-8. If there is a better way of ensuring this is not installed in a way that introduces incompatibility, I would very much like to know.

Thank you for reading this and for any reply.

General

• This is a new package and it conforms to the quality requirements

Have the results of the proposed changes been tested?

• I use the packages affected by the proposed changes on a regular basis and confirm this PR works for me
• I generally don't use the affected packages but briefly tested this PR

[ericonr]

This looks reasoanble to me, though I don't use any of the related software.

@sgn ?

[sgn]

Hm, I would count broken euc-JP supports as regression. But, I'm not sure if anyone still uses euc-JP, nowaday.
I guess you're one of them? Let me see if I could restore euc-JP support.

I don't think the conflict is necessary, libanthy dependency will conflict with anthy-9100* anyway.

[Gorggg]

@sgn

I'm sorry, I was unclear. It isn't the EUC-JP support that is broken. In fact, my change removes EUC-JP support. The problem is that the newer versions of anthy output UTF-8, whereas the anthy backend to uim takes EUC-JP, preventing the correct conversion of kanji. Instead, the anthy-utf8 backend must be used with newer versions of anthy. That is why this change disables the backend meant to interface with old (EUC-JP) anthy.

I can remove the conflict, thank you for pointing that out.

[sgn]

@sgn

I'm sorry, I was unclear.

Sorry, It was me the one was unclear.

It isn't the EUC-JP support that is broken. In fact, my change removes EUC-JP support. The problem is that the newer versions of anthy output UTF-8, whereas the anthy backend to uim takes EUC-JP, preventing the correct conversion of kanji. Instead, the anthy-utf8 backend must be used with newer versions of anthy. That is why this change disables the backend meant to interface with old (EUC-JP) anthy.

I understood your arguments.
However, removing euc-jp looks like too arbitrary to me.
Debian had also removed euc-jp supports for a while then restore anthy because of bug #953616

Quoted from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953616

• If you have customized enabled-im-list on "stretch" system (in
  ~/.uim.d/customs/custom-global.scm) with uim-pref-gtk or other tools,
  uim sticks to use anthy instead of anthy-utf8 and fails kanji-conversion
  on upgraded "buster" system.

[Gorggg]

@sgn

Quoted from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=9536161

If you have customized enabled-im-list on "stretch" system (in
~/.uim.d/customs/custom-global.scm) with uim-pref-gtk or other tools,
uim sticks to use anthy instead of anthy-utf8 and fails kanji-conversion
on upgraded "buster" system.

This sounds like exactly the issue I had. I had added the conventional anthy backend (which used EUC-JP) to the custom im list. When I upgraded, kanji conversion failed because uim was still using the old backend even when anthy was upgraded to a UTF-8 version. That was what prompted me to submit this fix.

I guess this change is a bit selfish for my particular case, it was just very difficult to figure out why kanji input was suddenly no longer working and I wanted to spare other people that trouble. I was hoping that not working with the EUC-JP version of anthy would not be a problem, since an EUC-JP version is no longer in the repositories, but if otherwise I wouldn't want to break other setups.

Thank you for your time in addressing this.

[sgn]

I think we should ship a message/readme for this package? Would it be better?

[Gorggg]

@sgn

In that case, I would think the patch would properly be applied to the anthy package rather than this one, as it is the upgrade of anthy from version 9100h to 0.4 which would change the encoding, not any particular change in uim. I can try to create that if you would like.

[sgn]

Other Anthy based IME works fine, so I think it's irrelevant to them. uim would need a rev-bump soon for other reasons. I think it would make sense to put it in uim-anthy instead.