Bug #765343 is related to this one. On Fri, Feb 19, 2016 at 08:33:08PM +0100, Andreas Henriksson wrote: > > On Fri, Feb 19, 2016 at 08:52:25PM +0300, Anton Zinoviev wrote: > > > 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.
The unknown variables really have to be preserved because we have no idea what variables will be used by future versions of console-setup, X or other keyboard using applications. As for the comments, they should be preserved because this is not some registry of values like Gconf or the registry of Microsoft. This is a configuration text file maintained manually by the system administrator. > Consider the highly theoretical case of a very simple configuration > program only dealing with XKBLAYOUT and leaving other fields intact, > eg. XKBVARIANT. Well, XKBVARIANT is not exactly an unknown variable. :) > > 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?! Debian installer puts there a sensible value. > Also empty seems to be perfectly acceptable by/for X atleast.) I don't know what exactly X does when XKBMODEL is an empty string. On most architectures there is a default model which works in most cases (but some multimedia and game keyboards require a specific model to be fully supported). On hppa it is impossible to have any default model but X doesn't run on hppa... > > 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.... When I wrote 'XKBOPTIONS should never be empty' I didn't mean some program expects it not to be empty. I only meant that the user is going to be very upset if his XKBOPTIONS are removed. > I'm thinking a table with all known variables listed plus if they're > optional, default value, .... what else? Try 'man keyboard'. Then ask me, if there are any questions. :) > (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.) As for the systemd/localed, the only problem I can see there is that it removes the comments from the file. Other than that it seems ok -- it preserves the values of the unknown variables and it works correctly with spaces. > > 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. ;) I haven't made tests but I suppose that Gnome ignores the system-wide keyboard layout and always sets a user specific layout. If no other working environments are used (graphical or console based), then few people are going to miss the value of XKBOPTIONS because most of these options are not necessary to type the username and the password. This also has the additional benefit, also debatable ;) that the keyboard at the login window will be more or less standard. For example the keys CapsLock and Control are not going to be swapped. On the other hand, if we want to be able to configure system-wide keyboard layout not only for Gnome, then the only realistic solution for Debian based systems I can see is to keep XKBOPTIONS unchanged. This is so because console-setup puts there a very sensible value and it is more or less layout independent. But I am not sure that we really want to be able to configure system-wide keyboard layout for non-Gnome environments using gnome-control-center. There are other more powerful programs to do this. Therefore, despite the title of this bug report, we can consider it fixed if gnome-control-center doesn't remove the variable XKBMODEL. Deleting XKBOPTIONS is acceptable. In case it is difficult to preserve the existing value, you can use 'pc105' as a default value. Alternatively, the following table with default values can be used: Architecture Subarchitecture Model ----------------------------------- m68k atari ataritt m68k mac macintosh_old m68k Other pc105 powerpc amiga amiga powerpc Other pc105 Other pc105 Notice that m68k is no longer supported by Debian. Powerpc is supported but I don't know how many people use Gnome on Amigas... In this table the architecture is the string obtained by 'dpkg --print-architecture'. On m68k the subarchitecture can be obtained in this way: line=`sed -n 's/^Model.*: *//p' /proc/hardware` if [ "$line" = '' ]; then echo unknown return 0 fi subarch=`echo $line|tr A-Z a-z` case "$subarch" in *macintosh*|*powermac*|*powerbook*|*power*|*imac*|*powermac1*) subarch=mac ;; *atari*) subarch=atari ;; *) subarch=Other ;; esac On powerpc the subarchitecture can be obtained in this way: line=`sed -n 's/^platform.*: *//p' /proc/cpuinfo` if [ "$line" = PS3 ] || [ "$line" = Cell ]; then subarch=`echo $line|tr A-Z a-z` else line=`sed -n 's/^machine.*: *//p' /proc/cpuinfo` if [ "$line" = '' ]; then echo unknown return 0 fi subarch=`echo $line|tr A-Z a-z` fi case "$subarch" in *amiga*) subarch=amiga ;; *) subarch=Other ;; esac > 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. It preserves the unknown variables, so there is no need to do anything. > 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. Done: #815244. Anton Zinoviev