* Zbigniew Jędrzejewski-Szmek:
On Mon, May 27, 2019 at 09:13:50PM +0200, Florian Weimer wrote:
> * Tomasz Kłoczko:
>
> > On Mon, 27 May 2019 at 10:41, Florian Weimer <fweimer(a)redhat.com> wrote:
> >> I'm investigating whether it makes sense to switch to a scheme where
the
> >> glibc locale data is built from source, during package installation,
> >> based on the langpack configuration system. This is similar to what
> >> Debian does.
> >>
> >> The reason is that the compressed locale source code (without the
> >> charmaps, which are not strictly needed once we patch localedef)
Can you expand a bit on this part about patch?
localedef currently reads character conversion tables from charmap files
under /usr/share/i18n/charmaps. The same information is contained in
the gconv modules unconditionally installed under /usr/lib*/gconv.
Do I understand correctly, that the saving essentially comes from the
fact
that current glibc-langpack-en contains 14 localized variants (AU, BW, ZA,
US, ...), and only a subset of those could be generated in your proposal?
If so, would simply splitting glibc-langpack-en further into subpackages
be an alternative? E.g. glibc-langpack-en-US, glibc-langpack-en-AU,
... ?
In theory, yes, but that would result in a few dozen more langpack
packages.
The other variance is the supported single-byte charset (UTF-8,
ISO-8859-1, ISO-8859-15).
Thansk,
Florian