Unwanted RPM dependencies -size of glibc-common locales

[David Timms]

Jeremy Katz wrote:
> On Mon, 2007-06-04 at 22:59 +1000, David Timms wrote:
>> My second size concern comes from glibc-common, specifically the 
>> /usr/share/locale {283 MB}  ( but also and  /usr/share/i18n/ 10MB)
>>
>> I notice that there are dependencies listed in comps.xml for what gets 
>> installed when a language is chosen {eg dictionary and openoffice 
>> translations}. This could be extended to the gazillion locales supported 
>> by glibc and fedora. The maybe most commonly installed individual 
>> locales could be made into separate packages {guessing ! english french 
>> german spanish portuguese ? ?}, and then continent or similar for the 
>> rest of the locales {noting that there is often sub-locales for some 
>> reqions} {eg african latin-american asian european} ? Installing 
>> European would also get the more specific english/french/german loc's.
> 
> And your tradeoff is that instead you have X packages more worth of
> metadata to download to discover packages/updates.  
Let's say X was 10, would that be reasonable ?

> Plus more space spent on the rpmdb, etc.
Is it that inefficient ? Is 1 package with n referenced files have 
{significantly} less rpmdb usage than say 10 pack's with the same n/10 
files each ? Doesn't not having to update and track a smaller subset of 
files require less resources {storage/rpmdb/.rpm/headers}?

>  Splitting things like this out is a losing
> battle that really ends up costing more in the long-term that it helps.
Why is it worth it for openoffice ? or the dictionaries ?

> Not to mention that this stuff in comps is at best a crude hack that has
> all kinds of weird side effects and user interactions.
What would the future perfect situation for these linkages be ? to go 
away ? How would you go about it then ? Make it not possible ?

> Note that you can have RPM not install properly "tagged" locale files
> not installed by setting the %_install_langs rpm macro.
Can the installer do this ? I have already told the installer I want 
language X and other support for lang Y-m. Should the installer be 
setting this macro before it starts installing stuff ? How much quicker 
could the install be if it the installer didn't have to install the 
locale/language support a user doesn't want or need ? And all future 
package operations use the setting, whether from rpm/yum/pirut ?
This sounds like it could be the way to go about it for the general user 
case ?

>  But your
> tradeoff by doing this is you won't be able to use deltarpms 
Isn't this at the whole .rpm package level anyway ? or is it using the 
rpmdb on disk as the reference ? if so why would deltarpms not need to 
track the macro setting you mention {and not install the guff you don't 
want or need}.

> and to add
> locale support later, you have to entirely reinstall packages.
Enhancement request for rpm coming along the lines of...?
rpm -Uvh --lang-support "Turkish" or "All"
Let the user have control.

DaveT.