On Mon, 27 May 2019 at 10:41, Florian Weimer <fweimer@xxxxxxxxxx> 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). In other words your proposition is *not* about not any kind of reduction size but increase size of installed resources because those binary files which needs to be present will be increased by source of those binary files. Other thing is that generating those files on install-time elongates install time. Remember that dpkg does not have any kind equivalent of rpm %lang() tagging in packages descriptions. In that exactly context Fedora still does not properly setups /etc/rpm/macros::%_install_langs macro and instead setting that macro during install-time provides langpack packages (which IMO is at least engendering/design mistake/misunderstanding). kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
