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

[Anton Zinoviev]

On Fri, Feb 19, 2016 at 05:10:03PM +0100, Andreas Henriksson wrote:
> 
> > By the way, I was very surprised to find that gnome-control-center modifies a 
> > configuration file belonging to other package.  This is not something Debian 
> > policy permits.
> 
> If you want to get into policy discussion land you should know that
> /etc/default/keyboard is *not* a conffile (as far as I can see).

Now I can see how what I wrote can be confusing in Debian context.  When I wrote 
'conffile' I simply used it as an abbreviation for 'configuration file'.

The following is the relevant part in the Policy:

] If it is desirable for two or more related packages to share a configuration file 
] and for all of the related packages to be able to modify that configuration file, 
] then the following should be done:
]
] One of the related packages (the "owning" package) will manage the configuration 
] file with maintainer scripts as described in the previous section.
]
] The owning package should also provide a program that the other packages may use 
] to modify the configuration file.

In our case the "owning" package is keyboard configuration because this is the 
package which creates /etc/default/keyboard and maintains this file in the 
package scripts.  Since in the last sentence the Policy says 'should' and not 
'must' there is no need for keyboard-configuration to provice a modifying 
program.  (However, if the maintainters of systemd want to have such a program, I 
don't mind to provide one.)

My point, however, is this: any package modifying a foreign configuration file 
has to _at_least_ inform the maintainer of the owning package.  People are going 
to report bugs about broken configuration files against the respective owning 
package and if its maintainer is unaware that other packages are modifying it, 
then he will be unable to deal with such bugs properly.

> > Nevertheless, we do want the keyboard configuration to be user 
> > friendly, so I approve what gnome-control-center does, as long as it does it 
> > correctly. :)
> Suggestions on what correctly means here could be helpful.

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.  The modifying program, however, has to 
leave everything else intact: assignments of unknown variables, commented lines 
and blank lines.

> Is XKBMODEL= always expected to be written out to the file even
> if the value is empty? (or is it a bug in the parsers not handling
> when its missing? I'd say normally you want parsers to be liberal
> in what they accept.)

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

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.  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).

> 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.

Anton Zinoviev