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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
