Some analysis on the size of the minimal and Server installs of Fedora 23

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Thu Nov 19 00:46:16 UTC 2015


On Wed, Nov 18, 2015 at 10:15:58PM +0000, Richard W.M. Jones wrote:
> On Tue, Nov 17, 2015 at 02:01:56PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > Is there any progress on
> > https://fedoraproject.org/wiki/Changes/Glibc_locale_subpackaging
> 
> I think it's this BZ:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=156477
> 
> in which case it looks like it's done (I didn't test it though ...)
> 
> It doesn't help unless you use the special _install_langs define when
> installing glibc, and then you've got to choose which locales you want
> to install, which I suppose will make some speakers unhappy.

Thanks, #156477 is very interesting. It seems to work as designed,
/usr/lib/locale/locale-archive becomes nice and small.

Couple of questions though:

1. Why even install non-utf8 locales? Shouldn't they be killed with fire?

  glibc defaults to including them,
  (e.g. %_install_langs=en_US includes en_US.iso88591, en_US.iso885915, en_US.utf8)
  but this approx. triples the size of /usr/lib/locale/locale-archive.

  https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base.ks
  uses %_install_langs C:en:en_US:en_US.UTF-8 which installs C C.utf8
  POSIX en_AG en_AG.utf8 en_AU en_AU.iso88591 en_AU.utf8 en_BW
  en_BW.iso88591 en_BW.utf8 en_CA en_CA.iso88591 en_CA.utf8 en_DK
  en_DK.iso88591 en_DK.utf8 en_GB en_GB.iso88591 en_GB.iso885915
  en_GB.utf8 en_HK en_HK.iso88591 en_HK.utf8 en_IE en_IE.iso88591
  en_IE.iso885915 at euro en_IE.utf8 en_IE at euro en_IN en_IN.utf8 en_NG
  en_NG.utf8 en_NZ en_NZ.iso88591 en_NZ.utf8 en_PH en_PH.iso88591
  en_PH.utf8 en_SG en_SG.iso88591 en_SG.utf8 en_US en_US.iso88591
  en_US.iso885915 en_US.utf8 en_ZA en_ZA.iso88591 en_ZA.utf8 en_ZM
  en_ZM.utf8 en_ZW en_ZW.iso88591 en_ZW.utf8 which is unlikely to be intentional.

2. What about non-glibc stuff? /usr/share/locale/ is 800MB on my system. It
  would be nice to trim this down too. Afaics, #156477 or the glibc
  subpackaging proposal will not help here at all.

Zbyszek


More information about the devel mailing list