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) is smaller than the subset of locales of a langpack package which people actually. For example, glibc-langpack-en on Fedora 29 is 6.7 MiB when installed, but en_US.utf8 is 2.9 MiB, and the locale sources are 3.4 MiB, so even the common case realizes a small saving.
For the installer, the savings might be much larger. If we can teach anaconda to generate the appropriate locale only after the user has selected the language, then we no longer need the full locale archive in the installation image (and in RAM).
Thanks, Florian
On Mon, May 27, 2019 at 5:36 AM Florian Weimer fweimer@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.
May I wildly discourage this? It's too sensitive to local libraries and binary updates, and reduces stability for what should be a very stable package.
On Mon, May 27, 2019 at 5:36 AM Florian Weimer fweimer@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) is smaller than the subset of locales of a langpack package which people actually. For example, glibc-langpack-en on Fedora 29 is 6.7 MiB when installed, but en_US.utf8 is 2.9 MiB, and the locale sources are 3.4 MiB, so even the common case realizes a small saving.
For the installer, the savings might be much larger. If we can teach anaconda to generate the appropriate locale only after the user has selected the language, then we no longer need the full locale archive in the installation image (and in RAM).
I'm generally opposed to this because it introduces a scriptlet requirement fairly early on in the system and I don't consider it to be significant enough. If we wanted to have savings here, we should look at encoding finer-grained locale attributes to the files in the package file list so that rpm locale filters can strip them.
Even without this, I don't think the savings are worth it as you propose.
-
Florian Weimer -
Neal Gompa -
Nico Kadel-Garcia