F23 System Wide Change: Glibc locale subpackaging

[Kevin Kofler]

Jan Kurik wrote:
> Currently the file /usr/lib/locale/locale-archive contains all locales and
> is thus huge (103MB). For small systems (and containers) it would be
> useful to be able to install only a small number of locales.

That makes a lot of sense indeed.

> Recently we made it possible to install a small number of locales by
> supplying the rpm-macro “_install_langs”, for example
> 
>    rpm -i -D _install_langs="en:de_DE" glibc-common.rpm
> 
> will install all English locales and all German locales which start with
> “de_DE”,
> 
>    rpm -i -D _install_langs="en_US.utf8" glibc-common.rpm
> 
> will install only the en_US.utf8 locale,
> 
>    rpm -i -D _install_langs="POSIX" glibc-common.rpm
> 
> will install nothing (but the POSIX/C is still available because it is
> builtin into glibc).
> 
> But this approach works only during an Anaconda based install when
> Anaconda supplies the _install_langs rpm-macro. When glibc is updated
> later, the _install_langs macro will not be supplied on the command line
> during the update and the default value “all” of “_install_langs” from
> /usr/lib/rpm/macros will be used and all locales come back during an
> update.

This is exactly the same as for all other packages, and this is why you are 
supposed to also define _install_langs in your /etc/rpm/macros (and Anaconda 
should really do that when using --instLangs). I don't see how glibc is 
special there.

> Therefore, this solution is far from perfect. It should be made possible
> to install and uninstall locales individually, for example by having a
> separate package for the locales for each language. Installing such a
> package would add these locales to locale-archive, uninstalling it would
> remove them.

Sure, in principle, that's easier to work with than the _install_langs hack 
where the only documented way to get the translations back is to reinstall 
packages, but doing this properly would mean to have langpack subpackages 
for ALL packages, not just glibc. (And, to be honest, I'm not convinced that 
that would scale.) I don't think a glibc-only solution really fixes the 
problem at hand.

> Anaconda then needs to be changed to handle such language packages.

So this too requires Anaconda changes? Then why not just make the (probably 
one-line, or at least < 10 lines) change to make --instLangs permanent 
automatically (through /etc/rpm/macros) instead? (And until that happens, it 
can be worked around by a one-line addition to the kickstart.)

        Kevin Kofler