[Pkg-ime-devel] Bug#708847: ibus: provide default input methods if one is not specified

[Drew Parsons]

On Sun, 2013-05-19 at 18:37 +0900, Osamu Aoki wrote:
> > One of the design philosophies in Debian is that packages should
> > generally "just work" when installed.  
> 
> Yes.

Thanks for allowing the discussion to take place.  It sounds like the
cyclic dependency is the point to think through.


> > At the moment ibus does not do
> > this: if you install the ibus package, no input methods are included.
> > Hence a default installation does not work.  
> 
> Really :-)  It support xim method.

Perhaps.   But I understand that xim is precisely the problem that ibus
and fcitx are designed to solve... :)


> > (fcitx has the same problem, I mentioned it in bug #708149 but I think
> > I should file a separate bug for it, parallel to this bug in ibus)
> 
> This is intentional choice with reasons.  If we were to make such
> utitily package as ibus-all-popular and fcitx-all-popular, this may be
> made to pull in many packages.  We did not do this.
> 
> Please see how CJK language localization tasks pick IM packages.
> 

It certainly is reasonable to want to not pull in unneeded packages.  In
principle my "xorg-like" mechanism would satisfy that through the 
"popular | specific" condition. The localization tasks would include the
specific input method they need, and therefore the other input methods
would not be pulled in.

> Japanese ibus-anthy ibus-mozc are your pick (But current Japanese task
> maintainer chose to use uim.  So he has uim-anthy uim-mozc.) 

Thanks for the correction for preferred Japanese input.  I haven't
tested uim yet. Looks like the same question I'm raising would apply to
it too.  If I can convince you to adjust for the input-method-popular |
input-method-specific dependency, then perhaps a general mechanism could
be designed, say by expanding the scope of im-config (but that would
probably introduce unnecessary anbd therefore undesirable complexity).


> I have not thought through but do you claim this does not cause cyclic
> dependency for sure.  Unlike xorg cases, these ibus-hangul depends on
> ibus.

Ah, I didn't catch that the ibus input methods Depend on ibus.  That
complicates it a little.  It's a bit different with fcitx, which uses
Recommends rather than Depends (which I think would not count as a
cyclic dependency).

Best then to lay down the use cases.  I think there are only two.

1)  Native speaker who wants immediate access to their own language.
This user will see the input method for their language and select it for
installation.  It's reasonable for that to be the only action they need
to take.   This is the use case you currently have in place.  When an
ibus input is selected, it pulls in ibus (via Depends, but would
Recommends be sufficient?) to provide the required framework.

2) Non-native speaker who just wants access to other languages, without
expecting to routinely use them every day (this is the casual user I
invoked).  This user doesn't know the difference between anthy, mozc and
skk. For educational purpose they may want each of Chinese, Japanese and
Korean installed.  They hear that ibus integrates well with Gnome and
select it for installation.   My suggestion is that it's reasonable for
them to gain an ibus installation which is already ready to sue.


The sticking point, then, is that currently the ibus input methods
Depend on ibus.   Would you consider changing this to a Recommends?  I
believe this will continue to support Use Case 1, so it will continue to
work the way you intended.   Then I think with a Recommends
relationship, my mechanism would be able to support Use Case 2 without
introducing a cyclic dependency.  Recommends doesn't cause a cyclic
dependency, does it?

A Recommends would mean that a user may explicitly choose to uninstall
ibus while leaving the input method installed.  I think this would come
under the category of "expert user", one who knows what they're doing.
We don't need to force the decisions of those users.  Maybe they want
access to the ibus data files to help port an input method to uim :)

> > It's easy for me to generate a patch for you, let me know if that would be
> > helpful.
> 
> Yes patch and also policy conformance explanation.  Otherwise, we will
> not be doing concrete discussion.

Thanks.  I'll wait to hear what you think of my policy interpretation,
with the suggestion to use Recommends instead of Depends.  I'll generate
some patches if you give the thumbs up :)

Drew

p.s. good luck with the extended Gnome integration :)




> Osamu
>  -- no debconf information