Bug 229742 - groupremove lang-support makes scim unusable for other languages
groupremove lang-support makes scim unusable for other languages
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: comps (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Cantrell
: i18n
Depends On: 223975 244770
Blocks: FC7Target
  Show dependency treegraph
 
Reported: 2007-02-22 21:05 EST by Jens Petersen
Modified: 2014-01-21 17:57 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-13 21:28:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
comps-fc7-core-scim.patch (18.07 KB, patch)
2007-04-11 04:31 EDT, Jens Petersen
no flags Details | Diff

  None (edit)
Comment 1 Jens Petersen 2007-02-22 21:12:39 EST
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@redhat.com on 2007-01-23 08:46 EST --
Created an attachment (id=146297) [edit]
Text file with some outputs

-- Additional comment from petersen@redhat.com 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@redhat.com 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.

Comment 2 Jens Petersen 2007-02-22 21:18:29 EST
> 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.
Comment 3 Jens Petersen 2007-03-21 02:55:05 EDT
Any more ideas or comments on this?
Comment 4 Jeremy Katz 2007-04-10 15:42:48 EDT
(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.
Comment 5 Jens Petersen 2007-04-11 04:25:19 EDT
(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).
Comment 6 Jens Petersen 2007-04-11 04:31:17 EDT
Created attachment 152257 [details]
comps-fc7-core-scim.patch

Here is a patch that implements the required scim package changes in comps.
Comment 7 Jesse Keating 2007-04-11 10:58:01 EDT
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?
Comment 8 Jens Petersen 2007-04-11 21:49:47 EDT
(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.
Comment 9 Jesse Keating 2007-04-13 21:28:42 EDT
Ah ok, I'll apply then.

Note You need to log in before you can comment on or make changes to this bug.