[systemd-devel] [PATCH] localed: search locale settings on kernel cmdline first

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 01, 2014 at 04:36:47PM +0200, Lennart Poettering wrote:
> On Tue, 01.07.14 16:47, microcai (microcai at fedoraproject.org) wrote:
> 
> > > Maybe another option is to improve localectl on the client side to
> > > simply warn the user if there's something on the kernel cmdline
> > > specified? (this check should probably test this directly, bypassing
> > > localed, and thus get skipped if localectl is used on a remote host).
> > > 
> > > i.e. just a simple warning if you type "localectl" that says: "Warning:
> > > Locale configuration has been specified on the kernel command line,
> > > overriding the system settings below." or so...
> > 
> > kernel has BOOT time, etc settings has modified time, which one is newer, take 
> > that ?
> 
> I am pretty sure we should stay with the simple logic of "kernel
> cmdline overrides /etc". Trying to be smarter and saying newer /etc
> overrides older /proc/cmdline will just be confusing, and has not been
> used anywhere so far...
One of the nice things about localectl set-locale was that it acted
immediately. We should keep this property. So I think that the patch
as is causes a usability regression, for things which are not started
by systemd, and use /etc/locale.conf instead.

OTOH, the difference in behaviour between systemd and localed is annoying
and potentially confusing.

I think we should

1. make systemd and localed use the same logic, which follows the line
proposed by microcai, so that a newer /etc/locale.conf wins over the
commandline, which wins over an older /etc/locale.conf.

2. make localectl generate a warning if anything is set on the commandline,
that those settings will take precedence after reboot.

This will keep the possibility to use dynamic configuration, and give
the admin a hint and a chance to update or clean up the commandline.

I don't think that the argument that /proc/cmdline always wins is valid.
For example root filesystem settings, logical volumes, the default unit,
additional units to get started, filesystems to be mounted, are all things
which are often dynamically altered at runtime. I don't think we should
sacrifice usability for narrow consistency.

Zbyszek