Bug#815154: gnome-control-center removes XKBMODEL and XKBOPTIONS from /etc/default/keyboard

[Andreas Henriksson]

Hello Anton Zinoviev.

Thanks for quick followup.... I sympathize with being left to debug
a "corrupt" file which you don't know if your tool wrote or not, while
not having any (for the moment known) way to reproduce the problem.

On Fri, Feb 19, 2016 at 08:52:25PM +0300, Anton Zinoviev wrote:
[...]
> In my opinion "correctly" (in this case) means this:
> If some configuration program wants to modify the value of some variable in 
> /etc/default/keyboard, it can do so.

I agree about this interpretation.

> The modifying program, however, has to leave everything else intact:
> assignments of unknown variables, commented lines and blank lines.

I don't think this is good advice however.

Consider the highly theoretical case of a very simple configuration
program only dealing with XKBLAYOUT and leaving other fields intact,
eg. XKBVARIANT.

Consider the difference between:

XKBLAYOUT="us"

... and ...

XKBLAYOUT="us"
XKBVARIANT="dvorak"

I bet a person who ends up with the latter when expecting the
former would be really surprised.


Also consider what this theoretical program which toggles between
us and swedish layout would do to this file:

XKBLAYOUT="se"
XKBVARIANT="dvorak"

What does ^^^^ mean? Possibly "svorak" (which is an actual layout) but
I'm not sure the above is the correct syntax for that.

IMHO leaving unknown fields untouched is to be considered harmful.

(fwiw, I'm a user of us-dvorak + swedish (qwerty) myself, as well as
someone who highly dislikes svorak.)

[...]
> XKBMODEL has no default value (at least in console-setup).  It should
> always be present and never as empty value.

(If there's no default, how can it be expected to never be empty?!
Also empty seems to be perfectly acceptable by/for X atleast.)

> 
> XKBOPTIONS is not necessary in which case empty value is assumed.
> Notice however that XKBOPTIONS should never be empty (or missing) when
> the keyboard is for a non-Latin language.

Thanks for this advice. I think it would be great if we could formalize
the expectations programs parsers (and writers) of /etc/default/keyboard
can make on a wiki.debian.org page or similar....

I'm thinking a table with all known variables listed plus if they're
optional, default value, .... what else?

(Once it's more clear to me I'll volunteer trying to improve the debian
systemd/localed patch to follow your advice when I find time, unless someone
else beats me to it. Main question would be the one in paranthesis above.)

> Since gnome-control-center doesn't provide means to configure
> XKBOPTIONS, I suppose it will be best if it leaves the current value
> unchanged (this is debatable).

As discussed above I don't really agree and appreciate this being
debatable. ;)

For model and options (which is part of the SetX11Keyboard dbus API)
gnome-control-center would have to read out the current setting and pass
it back when setting it again if we want to follow your suggestion as
there's (as far as I can see) is no way to signal over the dbus api to
"leave value unchanged".

For other (unknown) values the systemd patch would need to be changed as
it currently only reads out a fixed set of variables (those matching the
known set included in the dbus apis) and unlinks the existing file on
writing out new settings.

Before implementing any of the above I really think we should think
twice about it though. As mentioned I think leaving unknown fields
untouched can lead to unexpected results and it's much better to
always consider any reconfiguration as the full details of the wanted
new configuration setting.

> 
> > I also noticed that patched localed writes out the file without the
> > values quoted.... is that considered required?
> > eg. FOO="bar" becomes FOO=bar when localed writes the file.
> 
> Thank you for noticing this. It doesn't matter whether it will be FOO="bar" or 
> FOO=bar, as long as bar doesn't contain spaces.  I don't know if there is any 
> configuration program which puts spaces there, but both console-setup and X 
> permit spaces, so the sysadmin may put spaces there.  I've just tested that 
> gnome-control-center doesnt work properly when the values contain spaces (for 
> example when XKBLAYOUT="us, fr").  Fortunately, it doesn't put spaces in bar. 
> However it erases some parts of the string.  This is another bug.

Thanks for looking into this and I also think we should continue that
discussion in a separate bug report to keep focus on the more important
and practical problem in this bug report.

Regards,
Andreas Henriksson