It should not happen. But it looks strange where things gone wrong that made m17n-contrib-marathi to be installed on your system.
Is this F-11 gold installation with no updated applied?

On my F11 system I got,
repoquery -q --whatrequires m17n-contrib-marathi
scim-lang-marathi-0:1.4.8-3.fc11.x86_64

(In reply to comment #1)
> Is this F-11 gold installation with no updated applied?

no, I did some updates - in fact, I've noticed these packages when reviewing what does the yum want to update today

just to be sure, I am going to retry with image linked as
http://download.fedoraproject.org/pub/fedora/linux/releases/11/Live/i686/Fedora-11-i686-Live.iso and report back

'input-methods' is a default-on group in comps. If you don't deselect it, you get a variety of input methods.

(In reply to comment #3)
> 'input-methods' is a default-on group in comps. If you don't deselect it, you
> get a variety of input methods.  

I was not knowing this thing before. Any reason to mark input-method as default-on group in comps?

It is intentional and allows Live to support Asian users for example.
Sorry but 1MB is nothing ;) though @input-methods takes up plenty
more than that of course...

We haven't been flooded with complaints about it but I hear
what you're saying and you are not the first to raise this
recently so maybe we need to revisit the comps defaults again.

(In reply to comment #2)
> just to be sure, I am going to retry with image linked as
> http://download.fedoraproject.org/pub/fedora/linux/releases/11/Live/i686/Fedora-11-i686-Live.iso
> and report back  

so, the result is ... I can't tell, because of the bug #518621 - but it seems irrelevant, due to the other comments

(In reply to comment #5)
> It is intentional and allows Live to support Asian users for example.

I'm afraid I'm not getting the connection between what is supported by the Live and what should get _installed_ by default?

> Sorry but 1MB is nothing ;) though @input-methods takes up plenty
> more than that of course...

uff, the whole group takes more than 70 MB ...

> We haven't been flooded with complaints about it but I hear
> what you're saying and you are not the first to raise this
> recently so maybe we need to revisit the comps defaults again.  

while I want the Asian people to be supported, I don't want to pollute their systems with Central European support, and I hope that it can work the other way round too :-)

I wonder what are the reasons for the others raising the issue, for example someone likes to measure the default installation time (that is increased by this) or whatever, but I simply don't like wasting the resources - 70 MB seems nothing talking about desktop, but if you're trying to get Linux onto a phone with 256 MiB internal storage (oh, and what was the hardware of OLPC?) ...

(In reply to comment #6)
> I wonder what are the reasons for the others raising the issue, for example
> someone likes to measure the default installation time (that is increased by
> this) or whatever, but I simply don't like wasting the resources - 70 MB seems
> nothing talking about desktop, but if you're trying to get Linux onto a phone
> with 256 MiB internal storage (oh, and what was the hardware of OLPC?) ...  

To be fair... if you're putting it on a phone or an OLPC, you're not using the default install.

(In reply to comment #7)
> To be fair... if you're putting it on a phone or an OLPC, you're not using
> the default install.  

true ... I just wanted to say that relying on the fact that no one wants to run stock Fedora on anything worse than at most two years old middle class office/multimedia desktop PC is a bit unfortunate

if it was for some useful feature, ok, let's move on - but if it's just to store bits that are never used for their purpose, they just cause unnecessary load, then it seems to me a bit weird

imagine that you have a car and in that car, instead of using that car's cargo space for what do you want you just store various things that you have no use for but that are used somewhere around the world ... after a few years you find that you feel a bit claustrophobic and you buy a bigger car and you find that it is alredy preloaded with all those things, and you don't get so much free space as it would seem just by comparing the cars' cargo space sizes ... and you find that you cannot buy a small "city" car, 'cause you wouldn't fit the things you like to use in it as they are bound hard to those things you don't want to use

this sounds quite strange - so, why do people consider this OK for computers?

I know the analogy is not perfect - you can argue that you can use old software with the old hardware, but then you wouldn't get e.g. security updates that are still needed for the whole hardware lifetime (ok, extend the analogy - like the oil type you need to use in your car would not be available any longer)

and you can argue that there are other distros than Fedora, but ... can you name one *major general purpose* distro that would not be such resource hungry? - I really don't want to use some "hey guys let's try to fit the software I use on a bussiness card size dvd" projects, that are really hard to bend to my needs and that I have no guarantee they will not cease to exist tomorrow

sorry for this longer post, it's bugzilla here, not a discussion board ... well, it's Monday morning here in CEST and it takes some time to get into the mood for some real work :-)

Ok my plan now then is to no longer make @input-methods default
for normal installs and add the group to Live spin-kickstarts.
We might need some meta packages too for easier post-installing
of input methods.

(In reply to comment #8)
> true ... I just wanted to say that relying on the fact that no one wants to run
> stock Fedora on anything worse than at most two years old middle class
> office/multimedia desktop PC is a bit unfortunate

Don't worry, seven years old cheap computers are still running Windows XP,
and I suppose Fedora is still slimmer than that. :-)
Oh, Windows XP does have various IMs in their CD.
 
> if it was for some useful feature, ok, let's move on - but if it's just to
> store bits that are never used for their purpose, they just cause unnecessary
> load, then it seems to me a bit weird.

IM and other i18n features are like device drivers, most of them are redundant,
however, the system is unusable if the ones you needs are absent.

Imaging what people will react if only intel, nvidia, and ati video drivers are kept in fedora.

On the other hand I feel like this change may be a step back
in some sense: it is a bit like all the device or video
drivers installed by default though most of them are not needed.

I can explain though that one of the main reasons for
@input-methods is the problem that of getting the
right immodules installed at the same time:
this can't really be done with package dependencies
since it depends on whether you are using gnome or kde.
Installing all input-methods has helped fedora-i18n
not having a answer the FAQ how do I install "my favourite"
input method... so we may leave this open until we
solve that problem.

I think a better solution for now is to add "Input Methods" to
anaconda's Package Selection page

https://fedoraproject.org/wiki/File:Tours_Fedora11_004_Install_PackageSelection.png

that would make it very easy to uncheck/check input methods
at install time.

(In reply to comment #10)
> Don't worry, seven years old cheap computers are still running Windows XP,
> and I suppose Fedora is still slimmer than that. :-)

from what I recall, Windows XP runs on 128 MiB RAM (haven't seen such configuration for a while), which is not enough even for the Fedora installation ...

> IM and other i18n features are like device drivers, most of them are
> redundant, however, the system is unusable if the ones you needs are absent.

yes, but you need them all just on the installation media, you don't need to copy every bit to the harddrive - just like you don't include every module within the initrd image, for example

most people consider the system unusable without a webbrowser, but we don't install all the available browsers by default, right?

(while the drivers are bound to specific hardware, you can say that some pages are best viewed with this and others with that ... so, where's the line, why don't we install a browser good for some pages while they can be viewed somehow by another browser, and we do install a driver good for some hardware that can be driven also by another, more generic, driver?)

(In reply to comment #11)
> On the other hand I feel like this change may be a step back
> in some sense: it is a bit like all the device or video
> drivers installed by default though most of them are not needed.

which is not good too, IMO

> I can explain though that one of the main reasons for
> @input-methods is the problem that of getting the
> right immodules installed at the same time:
> this can't really be done with package dependencies
> since it depends on whether you are using gnome or kde.
> Installing all input-methods has helped fedora-i18n
> not having a answer the FAQ how do I install "my favourite"
> input method... so we may leave this open until we
> solve that problem.  

ok, let's do the things properly, don't remove @input-methods until a reliable way how to get it if needed is prepared

btw, as a temporary remedy (and hopefully a part of the future fix), is that possible to make it conditional - if a language that uses it is selected at the beginning of the installation then default to install @input-methods, otherwise do not install it?

Created attachment 358533 [details]
anaconda-input-methods.patch

a small patch to implement the change in anaconda

(In reply to comment #13)
> btw, as a temporary remedy (and hopefully a part of the future fix), is that
> possible to make it conditional - if a language that uses it is selected at the
> beginning of the installation then default to install @input-methods, otherwise
> do not install it?  

We already basically do that: eg if you do a Japanese install
you will get Japanese IME installed, etc: which is why
we can consider making this change.  The problem is
even many Asian users seem to install in English... :-/

Consider this:  Does the end user have any idea what "Input Methods" is?  Seems unlikely to me.  Given this, why present the confusing choice of it as a top-level group?

Much as I hate to suggest this, perhaps the input-methods packages should be treated conditionally, like the rest of the i18n stuff is.

(In reply to comment #16)
> Consider this:  Does the end user have any idea what "Input Methods" is?

Good point.  We can make the text more descriptive.
How about "Asian language input method support".

> perhaps the input-methods packages should be
> treated conditionally, like the rest of the i18n stuff is.  

You mean like lang-packs?  But conditional on what?

IMHO we should try to reduce the number of conditional packages
in comps not increase them.  Conditional packages are confusing
to users and not well supported by yum or packagekit.

The idea here is just to offer a quick and easy way for people
who don't need them to avoid installing (and updating/removing)
the default set of input methods, just like they can choose
not to install OpenOffice, etc.

(In reply to comment #13)
> (In reply to comment #10)
> > Don't worry, seven years old cheap computers are still running Windows XP,
> > and I suppose Fedora is still slimmer than that. :-)
> 
> from what I recall, Windows XP runs on 128 MiB RAM (haven't seen such
> configuration for a while), which is not enough even for the Fedora
> installation ...

Your original question was: 2 year old mid range computer.
I have a 2005 hp compaq nc 6120 which has 256M memory.
I just test last night. Fedora 11 Live USB seems pretty happy about it.
> 
> > IM and other i18n features are like device drivers, most of them are
> > redundant, however, the system is unusable if the ones you needs are absent.
> 
> yes, but you need them all just on the installation media, you don't need to
> copy every bit to the harddrive - just like you don't include every module
> within the initrd image, for example

Unfortunately, you do install whole set of X video driver (and couple of input driver), which most of them are not for your system.

> 
> most people consider the system unusable without a webbrowser, but we don't
> install all the available browsers by default, right?
With KDE, you do install two browsers by default, firefox and konqueror.

Nevertheless, browser analog cannot apply here.
You can use either Firefox, opera, chromium, konqueror to open nearly all web pages. But you cannot type Korean throught a Chinese input method.

> 
> (while the drivers are bound to specific hardware, you can say that some pages
> are best viewed with this and others with that ... so, where's the line, why
> don't we install a browser good for some pages while they can be viewed somehow
> by another browser, and we do install a driver good for some hardware that can
> be driven also by another, more generic, driver?)
If we take browser view that serious, we should install all of them by default. :-)
But since you concern about the resource, thus Firefox is the only default for non-KDE spin.

In reply to comment #17)
> (In reply to comment #16)
> > Consider this:  Does the end user have any idea what "Input Methods" is?

I don't think people will intentionally install unfamiliar packages in a resource-tight system.

If resouorce is not a problem, then whether to install is not a problem either. :-)

> Good point.  We can make the text more descriptive.
> How about "Asian language input method support".
> 
> > perhaps the input-methods packages should be
> > treated conditionally, like the rest of the i18n stuff is.  
> 
> You mean like lang-packs?  But conditional on what?

I think what he mean is that installation of input method should depend on
locale setting in the beginning.

As for Asian en_US users, having a "Input method/Asian language support" 
option in anaconda helps them to install i18n packages for them.

Perhaps the input-method packages should either (1) be made a part of the various language support groups, or (2) be made conditional on those groups being selected.  Doing #2 would ensure that choosing a language in anaconda would get you the correct input-method packages without having to select them manually.

(In reply to comment #20)
> Perhaps the input-method packages should either (1) be made a part of the
> various language support groups, or (2) be made conditional on those groups
> being selected.  Doing #2 would ensure that choosing a language in anaconda
> would get you the correct input-method packages without having to select them
> manually.  

(1) is already true.  I think we mostly already do (2) for the immodules.

But the reason for this request was really to provide
a quick way for users who don't need input-methods
to avoid installing them.

What are the criterion for inclusion on the top-level group list?

The "top-level groups" (or tasks, as we sometimes call them) are entirely made up by anaconda, but generally map to major areas of functionality that a user might want to quickly enable/disable.  So for instance, you may want a web server setup, or a desktop setup, or whatever.  With a single click you can get that support or remove it if you'd like.  With that in mind, adding things to that list should be done only very rarely so as to not allow the task list to get too large and unusable.

I think until we have a safe way of installing immodules after
system install, we will continue to install @input-methods by default
for all users.  But I bet that the majority of Fedora users don't
need input-methods, so that is why I would like for them to be able
to say with one-click "my system doesn't need input-methods period"
and save about 60-70MB of install and updates, rather than taking
the challenge and entering the "Customize now" maze^Whierarchy. :)
You can think of it as a task to "input natively with input methods".
(In the same way that people who don't use openoffice.org, etc
can uncheck it there too.)

(BTW OT, but what happened to minimal server install?)

Ok a more radical approach might be to leave @input-methods on
by default for all users but to make all IMEs optional.
That would mean we would at least have appropriate immodules
in place after install but non-native installs would then need
to add appropriate IME for any required langs after install.

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

(In reply to comment #23)
> I think until we have a safe way of installing immodules after
> system install, we will continue to install @input-methods by default
> for all users.

Exactly

> But I bet that the majority of Fedora users don't
> need input-methods, so that is why I would like for them to be able
> to say with one-click "my system doesn't need input-methods period"
> and save about 60-70MB of install and updates, rather than taking
> the challenge and entering the "Customize now" maze^Whierarchy. :)
> You can think of it as a task to "input natively with input methods".
> (In the same way that people who don't use openoffice.org, etc
> can uncheck it there too.)
>

Quoting Chris from comment #16:

"Consider this:  Does the end user have any idea what "Input Methods" is?  Seems
unlikely to me.  Given this, why present the confusing choice of it as a
top-level group?"

Really this is not an anaconda issue, people also install 100 MB's of locale data they don't need:

[hans@localhost ~]$ du -s /usr/share/locale
572992  /usr/share/locale
[hans@localhost ~]$

Of which I need exactly 0 MB as my language setting is en_US. And this does not
even include openoffice, firefox and thunderbird language packs.

We used to offer the option to configure rpm's behavior to only install locale data for certain selected locale's, but we stopped doing that, as it is impossible to later on allow installation of additionalo languages without a complete re-install. And until this is fixed at the rpm / yum level there is little we can do.

The point I'm trying to make is, that when it comes to the diskspace (or bandwidth) / out of the box locale support discussion. So far Fedora has clearly made the we want to support every locale under the Sun out of the box
solution.

An input methods checkbox is an ugly band aid solution for the price this choice brings with it (and only solves a very small part of that price). If we truly want to allow people to configure which locale's they want better, we need a solution for the complete picture.

I'm more then willing to spend time making anaconda modifications for such a
complete solution, but we won't be putting all sort of ugly less then even half way there solutions in anaconda.

Hans, with all the respect, I must disagree with closing this bug

the point is not about considering some workaround which you do not like, the point is about making the user happier (:-) by not installing hundreds of megabytes of stuff that is not needed - and there is some user demand for it, as demonstrated recently at the fedora-test-list

so, let's return to the original summary - and if that needs some complete solution, let's keep it open until the complete solution is ready ... which you agree to participate in, so definitely not WONTFIX (unless I got you wrong?)

... eventually, a new bug (RFE) with clean description could be opened, making this duplicate of the new one

(but I'm not sure about the right component - yum?)

bugzilla is not the correct place for general technical direction discussions as needed for a complete solution for this, fedora-devel-list is.

Well I would like to try to make everyone happy on this issue.
(And I actually prefer focused discussion in bugzilla to
rants and petering out discussions in mailing-lists but if
I missed discussions on this I should catchup on it.)

Karel, the problem for me is if we don't install IM
(input-methods) by default then we have the opposite
and harder problem of teaching people how to install them.

yum groupremove input-methods /should/ do what you want
though it is not much tested I think.

(In reply to comment #29)
> Karel, the problem for me is if we don't install IM
> (input-methods) by default then we have the opposite
> and harder problem of teaching people how to install them.

from what I've learned from the discussion, the problem is not to teach people to install IM, but to teach them not to install in English, so that packages appropriate for the chosen non-English language can be installed automatically

> yum groupremove input-methods /should/ do what you want
> though it is not much tested I think.  

it worked for me and my system doesn't seem suffering any related troubles ... however, there is still plenty of l10n related packages left present that I have no use for (for example, recently I've noticed and removed lohit-tamil-fonts)

- but the point was trying to do minimal install, not about post-install removal

(In reply to comment #30)
> from what I've learned from the discussion, the problem is not to teach people
> to install IM, but to teach them not to install in English, so that packages
> appropriate for the chosen non-English language can be installed automatically

You can't do that in Live.

I tried to have easier way to avoid input methods in Anaconda
but they seem little interested in pursuing that approach.

> it worked for me and my system doesn't seem suffering any related troubles ...
> however, there is still plenty of l10n related packages left present that I
> have no use for (for example, recently I've noticed and removed
> lohit-tamil-fonts)

Fonts is outside this discussion and there are good reasons
for installing a default font for most languages.
But yeah we probably want some way to uninstall unwanted fonts too.

> - but the point was trying to do minimal install, not about post-install
> removal  

What do you mean by "minimal"? :)

(In reply to comment #31)
> > - but the point was trying to do minimal install, not about post-install
> > removal  
> 
> What do you mean by "minimal"? :)  

well, it all started by me trying to fit Fedora on 1 GB USB sticks we got from Red Hat, so I can say "anything that fits under 1 GB" :-)

in general, I just want to have installed only the things I really need, so "minimal" is the smallest possible package set that fullfills my needs ... for example, for some reasons (at least bug #480317), virtualisation is quite slow on my machine, and installing new virtual machines for testing is bigger and bigger pain with each bit that has to be copied and processed (these are my usecases, am I really alone for whom do the installed bits matter?)

Karel Volný,

We all do. We do have some long-term plan which address the l10n issue, one notable example is yum-plugin-langpack.

However, as Jesse Keating stated in <a href="http://www.pubbs.net/fedora/200810/4600/">this thread</a>, it is nearly impossible to make every one agree on the so called "minimal" set. You only need @core to boot, but apparently you need more that that. :-)

Maybe editing your own kickstart file helps. You can have exactly what you need and their dependencies (unfortunately). From my experience, starting from Fedora's live CD will be easier. system-config-kickstart is buggy, it does not even load its own saving.

Alternatively, would you mind saying which packages you need, we might be able to squeeze that in if space allow us.

(In reply to comment #32)
> > What do you mean by "minimal"? :)  
> 
> well, it all started by me trying to fit Fedora on 1 GB USB sticks we got from
> Red Hat, so I can say "anything that fits under 1 GB" :-)

Under 1GB is not minimal. ;-)

As far as minimal goes I really think we need a Base spin that can be
customized after install and I am seriously considering proposing
such a spin - not completely sure what it would contain yet, but
at least enough that one can run "yum install @my-desktop" etc. :)

> virtualisation is quite slow
> on my machine, and installing new virtual machines for testing is bigger and
> bigger pain with each bit that has to be copied and processed

Ok that sounds like a different bug. :)

But sure as Ding also said everyone wants their perfect custom desktop
in a just a few hundred MBs...

as for the progress on this issue ... I've tried to install Fedora 13 Alpha RC4 (netinst), I've chosen Czech language and a server package set, and these are the groups that got installed:

   Administration Tools
   Arabic Support
   Armenian Support
   Authoring and Publishing
   Base
   Czech Support
   Dial-up Networking Support
   Editors
   Educational Software
   Electronic Lab
   Engineering and Scientific
   Fonts
   Games and Entertainment
   Georgian Support
   Graphical Internet
   Graphics
   Hardware Support
   Hebrew Support
   Input Methods
   Inuktitut Support
   Japanese Support
   Java
   Korean Support
   Lao Support
   Legacy Fonts
   Mail Server
   MySQL Database
   Network Servers
   Office/Productivity
   Printing Support
   Russian Support
   Server Configuration Tools
   Sound and Video
   System Tools
   Tajik Support
   Text-based Internet
   Ukrainian Support
   Venda Support
   Web Server
   X Window System

um, we really don't speak/write Japanese here in Czech republic, I even did not know that something like "Venda" exists before, and I really don't want to have those Input Methods installed, as stated as the subject of this bug

about 4 GiB after the "basic" installation seems too much for a simple web/VCS/backup server :-/
(yes, I know I should blame also the other groups)

(In reply to comment #35)
> 
> um, we really don't speak/write Japanese here in Czech republic, I even did not
> know that something like "Venda" exists before, and I really don't want to have
> those Input Methods installed, as stated as the subject of this bug

Guess the Japanese tourists, immigrants, or Japanese course teachers in Czech still need them. :-)

> about 4 GiB after the "basic" installation seems too much for a simple
> web/VCS/backup server :-/
> (yes, I know I should blame also the other groups)    

If what you did is just tick on server package set without uncheck other groups. Then it is the expected behavior. 

Checking on server package set merely means you need additional server support, but it is an overkill to uninstall other non-server-related packages.

Guess an "uncheck all groups except core and your locale" button is more useful in your case. What you need to do is add the web/VCS/backup packages back.
No need to bother install languages, productive, X and other software you don't need.

(In reply to comment #36)
> Guess the Japanese tourists, immigrants, or Japanese course teachers in Czech
> still need them. :-)

probably, but they don't need them on _my_ system

> > about 4 GiB after the "basic" installation seems too much for a simple
> > web/VCS/backup server :-/
> > (yes, I know I should blame also the other groups)    
> 
> If what you did is just tick on server package set without uncheck other
> groups. Then it is the expected behavior. 

no, I tried to install *only* the server set

but no need to repeat, the unfortunate package selection was discussed recently on fedora-test-list

This is one of my long-standing gripes also.  I just did a fresh F13
install from DVD and then spent quite a lot of time removing 
un-asked-for fonts and other stuff for a bunch of Asian languages.

(In reply to comment #38)
> This is one of my long-standing gripes also.  I just did a fresh F13
> install from DVD and then spent quite a lot of time removing 
> un-asked-for fonts and other stuff for a bunch of Asian languages.    

Next time deselect the "Fonts" group.  It's a default group.

FWIW I just tested with installing F14 on 512M guest,
and it used to TUI installer, installed 198 packages
and used 620M of diskspace.  Of course that is probably
about as minimal as one can get and includes no working
networking...

Then I installed a F14 Webserver, and @fonts and @input-methods
but just the core ibus packages (ibus, ibus-gtk2, and ibus-gtk3),
since gtk2 (and gtk3) got installed on the gnome-desktop.
Installed size of 1040 packages was 2.4G.  (Not sure why
a webserver implies a gnome desktop though.)

Finally, tried Desktop install disabling @fonts and @input-methods
(and few others like @games and @printing): 2.8G and 1106 packages.

(I don't really recommend disabling @fonts, but if you can
live with just dejavu-fonts then maybe it works for you.)

If Hans still wants to do a more generic solution in
Anaconda that would be great, as he mentioned in comment 26.
I also tend to agree that installing all locales is not optimal,
specially for Minimal.  There is also the problem of Live parity though.

(In reply to comment #40)
> Then I installed a F14 Webserver, and @fonts and @input-methods

were not installed.

I'm no longer on the anaconda team, moving back to anaconda-maint-list.