[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Unwanted RPM dependencies -size of glibc-common locales

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]