* Hans de Goede:
Interesting idea, my first thoughts on this are that doing this
during installation time feels wrong. How are you going to figure
out for which languages to generate the locale data ? The language
can differ per user. e.g. on my system the system language is nl_NL,
for testing purposed, but I greatly prefer to have my apps in English,
so for the hans user it is en_US.
Today, you need to install multiple langpacks to cover this case. If we
can detect the requested langpacks at %post time (or in a trigger), then
we could mirror the current behavior.
Thinking out loud here, if we go this route I think the data should
be
under say /var/cache/locale and be generated on demand. E.g.
/var/cache/locale could be owned by a locale user/group and the binary
to generate these files could be suid or sgid locale; then glibc could
start this helper on demand if necessary. This would also remove the
need to add some support / hack to anaconda for this.
That looks a bit overengineered to me, and it would drive up
installation size again. We would also end up with diverging approaches
for container images (where the D-Bus daemon might not even run) and
other use cases.
Thanks,
Florian