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@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) Can you expand a bit on this part about patch? > >> 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. > > 2.9 MiB (compiled en_US.utf8 locale) plus 3.4 MiB (compressed locale > sources without charmaps) is 6.3 MiB, which is less than 6.7 MiB > (current installed glibc-langpack-en size). Hmm, the tradeoff is not very convincing: doing install-time shenanigans to save 400k doesn't seem like a great deal. 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, ... ? Zbyszek _______________________________________________ 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
