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

[Michal Sekletar]

On Wed, Jul 02, 2014 at 03:05:36AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> 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.

I agree with above points.

> 
> Zbyszek

Michal