Bug 229742

Description of problem:
installed all supported langauge for testing, then remove Hindi support with pirut,
it remove some basic SCIM package, which make scim Unusable for other language
(Indic)

How reproducible:
Everytime removing language

Steps to Reproduce:
1. install 2/3 Indic language
2. remove 1 of language
3.
  
Actual results:
it will remove scim-bridge-gtk, scim-m17n, other langauges stop work (INdic)

Expected results:
should not remove, so that other languge can continue 

Additional info:
attaching "groupremove hindi-support" output

-- Additional comment from aalam on 2007-01-23 08:46 EST --
Created an attachment (id=146297) [edit]
Text file with some outputs

-- Additional comment from petersen on 2007-01-23 18:41 EST --
Is there some way yum can support packages in multiple package groups better?

The problem here is that no packages explicitly require scim-bridge-gtk,
scim-m17n and scim-qtimm, but they are listed in most Asian Language Support
groups.  Perhaps we could make m17n-db-* require scim-m17n, but I don't see
such an easy solution for the other two packages.

-- Additional comment from katzj on 2007-01-29 14:01 EST --
Why aren't they required by something?  That's the _ONLY_ way we have to know
that a package is needed other than explicitly listing it.  And some sort of hacky 
  <packagereq type="multigroup">
or something just feels like it's fragile and going to break _more_ often.

> Why aren't they required by something?

We could make scim IME packages (the engines for each language) require
scim-bridge-gtk perhaps, but I don't think we want them to require
scim-qtimm say.  So no, there really isn't anything that can require them at
present.  In fact for Fedora 7 it is now more complicated since we have
scim-gtk, scim-bridge-gtk, scim-qtimm and scim-bridge-qt.  And for m17n
there is also support in uim (another IM).

> That's the _ONLY_ way we have to know that a package is needed other than
> explicitly listing it.

Sorry, explicitly listing it where?

>  And some sort of hacky 
>   <packagereq type="multigroup">
> or something just feels like it's fragile and going to break _more_ often.

Sounds like that would probably work.  As Fedora grows and now that we
are merging Core and Extras I can imagine this coming up in other areas too.
So I feel we need some kind of support for this kind of thing from
package manager.

Any more ideas or comments on this?

(In reply to comment #2)
> > That's the _ONLY_ way we have to know that a package is needed other than
> > explicitly listing it.
> 
> Sorry, explicitly listing it where?

In the package.  Where we express all other relationships between packages.
 
> >  And some sort of hacky 
> >   <packagereq type="multigroup">
> > or something just feels like it's fragile and going to break _more_ often.
> 
> Sounds like that would probably work.  As Fedora grows and now that we
> are merging Core and Extras I can imagine this coming up in other areas too.
> So I feel we need some kind of support for this kind of thing from
> package manager.

So, for a more radical idea... what if we moved scim into the base-x group (and
the other bits into the more base groups as well) instead of hackily trying to
only install it for certain locales?  We'd probably then not want it to pop up
the desktop widget by default except in locales where it's actually "useful",
but it would get rid of a lot of the hacky nature here.

(In reply to comment #4)
> So, for a more radical idea... what if we moved scim into the base-x group (and
> the other bits into the more base groups as well) instead of hackily trying to
> only install it for certain locales?  We'd probably then not want it to pop up
> the desktop widget by default except in locales where it's actually "useful",
> but it would get rid of a lot of the hacky nature here.

Ok, that sounds like the right way to fix this in comps.

On the scim side, as a first step I just unset the default hotkey for scim
(Ctrl-Space) for non-Asian locale (bug 235435).

Created attachment 152257 [details]
comps-fc7-core-scim.patch

Here is a patch that implements the required scim package changes in comps.

Hrm, the packages that would require say scim-m17n should still probably be
conditional in the language groups, or else you're always going to get scim-m17n
+ its depchain whether you have X or not.  Other than that the patch looks OK. 
Can you rework it for the above issue?

(In reply to comment #7)
Well, the languages that had m17n-db packages conditional on scim-m17n really
do not use scim-m17n normally so I would prefer to keep them optional.
The m17n-db packages do not require scim-m17n, since they can also be used
with other input method systems like uim.

Ah ok, I'll apply then.