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 (micro...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
