On Mon, May 27, 2019 at 5:36 AM Florian Weimer <fwei...@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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
