Hi,
On 27-05-19 14:49, Florian Weimer wrote:
* 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.
True (determine languages from installed langpacks), but that does not
cover the anaconda and livecd cases. If we do this ondemand, we could also
gain some space on the livecd.
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.
How would this driver up installation size, we need a tool for
generating the data anyways and whether the files live under
/usr/share/locale or under /var/cache/local does not change their
size.
We would also end up with diverging approaches
for container images (where the D-Bus daemon might not even run) and
other use cases.
I admit that the on demand approach has issues for containers and
atomic.
Anyways if you go this route, I do have 2 requests:
1) Please put the files under /var/cache/local, we really need to stop
putting generated files under /usr
2) Please use a trigger for generating the files rather then %post
scripts, AFAIK we are working towards eliminating scripts as much as
possible.
Regards,
Hans
_______________________________________________
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
