gnome-control-center removes XKBMODEL and XKBOPTIONS from /etc/default/keyboard
Anton Zinoviev
anton at lml.bas.bg
Fri Feb 19 17:52:25 GMT 2016
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
More information about the Pkg-systemd-maintainers
mailing list