Re: base-files: don't overwrite existing locale and define default LANG

[ahesford <ahesford@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/pull/39264#issuecomment-1867580017

Comment:
Thanks; I wasn't reasoning through the assignment properly.

There are still problems sanitizing input. For example, if somebody has a file like

```sh
LANG=en_US.UTF-8 # English
```

it will contain a trailing space after the change but is currently properly parsed. I don't know whether any of the consumers of locale variables would be harmed by the addition of spurious whitespace, but I'd be surprised if this *didn't* introduce problems.

I have not found any documentation on `locale.conf` besides systemd manual pages. As I said before (apparently elsewhere; I thought I commented here earlier), we should not feel compelled to abide by the restrictions imposed by systemd against using other shell features in the configuration. Because we offer no manual page on the file, the code is the documentation; the code documents that the file is simply sourced. (The limitation in systemd, I assume, is that it parses the file directly. We don't parse the file anywhere but in shell profiles.) Users may currently be exploiting that to add extra logic to the locale configuration.

What Red Hat does to interpret the file is an ugly kludge that we should avoid. If anything, I think the Arch way is preferable; just let a pre-set LANG gate the sourcing of the file and, if some users really care about more complex preservation of the whole gamut of variables, they can implement a custom `post-locale.sh` to do so. However, I again question the need for this. Given we have established precedent that `locale.conf` is just sourced by a shell, users should feel free to do things like

```sh
: ${LANG=my-lang}
```

if they need to preserve a pre-set value.

Whatever the final form looks like, we should include a manual page or at least fully define on the docs web site what we accept as a valid configuration.