On Tue, 2007-06-05 at 06:38 +1000, David Timms wrote:
> 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 ?
It's more like 40. Or 60. Because doing it by region doesn't really
help much -- languages are spoken across regions and trying to pigeon
hole them like that just doesn't work. Times however many packages this
is done for. It gets big _fast_.
> > 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}?
You end up having to track more copies of, eg, changelog data and other
things that are "common" across a src.rpm set. And yes, that's pretty
costly.
> > 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 ?
The argument for OOo was that downloading the 200M (at the time) package
was extremely painful. Hopefully as we move towards integrating presto,
that can be less of a reason. The total size of the OOo langpack
packages right now is 525M. Although part of that, iirc, was the way
that OOo bundles up its help and translations being ... less than
entirely efficient :)
For dictionaries, the argument is that they are maintained separately
upstream as separate projects with their own release schedules, etc.
Which is relatively reasonable
> > 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 ?
Yes. Because even though the intentions seem reasonable enough, doing
it in a sane way just isn't. At least, that's where I've come to after
trying three different times.
> > 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 ?
We used to set it. And then people asked how to add support for a
language after the install. And the answer was basically "you can't".
So we don't do that anymore. I'd be open to having a way of setting it
from, eg, kickstart which is much more likely to be being used in these
sorts of "small footprint" situations.
> 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 ?
It really wasn't that substantial of a change here.
> 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 ?
You can set it, but again, it's definitely not the thing you want to do
by default.
> > 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}.
deltarpms work by taking the bits you have on disk + the deltarpm and
combining them to recreate the update rpm. If you've opted not to put
some of those bits on the disk, then it can't recreate the update RPM.
> > 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.
How is rpm supposed to know where to get those packages from? They may
not even be _available_ to install anymore. That's why this path is
such madness
Jeremy
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
