Yeah this is annoying.  It's because Firefox was changed to Suggest/Recommend a langpack, even though this is superfluous for plain English users.  At least you can remove the unneeded package later.

Assignee: bugsquad => doktor5000
Source RPM: firefox or urpmi => firefox

(In reply to Thomas Spuhler from comment #0)
> 3.you are reqired to select either 
> 1. firefox-en_ZA 
> 2. firefox-en_GB
> 
> These should be recommendations.

They are recommendations. And currently there's no other way to get the correct language package for the users's locale automatically installed.

If you use --no-recommends those should not be shown.

Status: NEW => RESOLVED
CC: (none) => doktor5000
Resolution: (none) => WONTFIX

We could provide an empty firefox-en_US with the appropriate provides.

I agree, or even "firefox-en" if we want it to handle all possible locales that are not en_GB or en_ZA.

Or leave as is for the time being.
I thought it was strange that recommendations end up as requires.

(In reply to Thomas Spuhler from comment #5)
> I thought it was strange that recommendations end up as requires.

They're not.  Recommends/Suggests are automatically installed unless you explicitly disable this, but you can uninstall them afterward.  Upgrading using the installer of course does not disable them.  If you do the upgrade using urpmi, you could.  However, for desktops I wouldn't recommend that.

An empty firefox-en_US that would satisfy the recommends would probably be a good solution.

(In reply to Florian Hubold from comment #2)
> And currently there's no other way to get the
> correct language package for the users's locale automatically installed.

Well, this Recommends doesn't solve that problem either.  I'm not sure how urpmi orders things when multiple packages provide the same thing (other than prefer.vendor.list can be used for setting the top choice), but whichever one it chooses normally as the default choice will be installed for everyone, which I believe is en_GB.

(In reply to David Walser from comment #6)
> Well, this Recommends doesn't solve that problem either.  I'm not sure how
> urpmi orders things when multiple packages provide the same thing (other
> than prefer.vendor.list can be used for setting the top choice), but
> whichever one it chooses normally as the default choice will be installed
> for everyone, which I believe is en_GB.

According to me for i18n packages it chooses what fits your language.

(In reply to Samuel VERSCHELDE from comment #7)
> (In reply to David Walser from comment #6)
> > Well, this Recommends doesn't solve that problem either.  I'm not sure how
> > urpmi orders things when multiple packages provide the same thing (other
> > than prefer.vendor.list can be used for setting the top choice), but
> > whichever one it chooses normally as the default choice will be installed
> > for everyone, which I believe is en_GB.
> 
> According to me for i18n packages it chooses what fits your language.

Yep that's how it should work. urpmi automatically prefers the -l10n-xx package if the locales-xx package is already installed. 

FWIW, adjustments to individual firefox-l10n subpackages are difficult due to the way those are generated from a template spec, but I'll try to take a look what we can do for en_GB and en_ZA, maybe with an empty firefox-en_US as suggested by Stormi.

The only other general option that exists would be dropping all the separate -l10n subpackages, merging all files into one package and using %lang(xx) tags for every file in %files list. This would only install that file if the corresponding locales-xx packages is already installed. Although that would be overkill for live media, where multiple locales packages are installed and where it might waste a lot of space.
In addition it would be harder to maintain with the pretty frequent small changes in the list of languages that are available for firefox/thunderbird for each minor relase.

If you have other good proposals, I'm all ears.

(In reply to Florian Hubold from comment #8)
> (In reply to Samuel VERSCHELDE from comment #7)
> > (In reply to David Walser from comment #6)
> > > Well, this Recommends doesn't solve that problem either.  I'm not sure how
> > > urpmi orders things when multiple packages provide the same thing (other
> > > than prefer.vendor.list can be used for setting the top choice), but
> > > whichever one it chooses normally as the default choice will be installed
> > > for everyone, which I believe is en_GB.
> > 
> > According to me for i18n packages it chooses what fits your language.
> 
> Yep that's how it should work. urpmi automatically prefers the -l10n-xx
> package if the locales-xx package is already installed. 
> 
> FWIW, adjustments to individual firefox-l10n subpackages are difficult due
> to the way those are generated from a template spec, but I'll try to take a
> look what we can do for en_GB and en_ZA, maybe with an empty firefox-en_US
> as suggested by Stormi.
> 
> The only other general option that exists would be dropping all the separate
> -l10n subpackages, merging all files into one package and using %lang(xx)
> tags for every file in %files list. This would only install that file if the
> corresponding locales-xx packages is already installed. Although that would
> be overkill for live media, where multiple locales packages are installed
> and where it might waste a lot of space.
We then would have all of them installed if installed from the live media as we had some years ago? And upgraded with every firefox upgrade.
> In addition it would be harder to maintain with the pretty frequent small
> changes in the list of languages that are available for firefox/thunderbird
> for each minor relase.
> 
> If you have other good proposals, I'm all ears.

Maybe the best solution is what we have right now and leave this closed/wontfix