Package: xkb-data Version: 0.9-4 Severity: serious After upgrading to etch, I noticed that it is no longer possible to use locally adapted keyboard layouts. The reason is that the contents of /etc/X11/xkb/ have been moved to /usr/share, and files at the old location are no longer used.
I think that it is clear that these files actually are configuration files. This has been discussed for example in #326637. Reading through this bug, one gets the impression that everyone who spoke up agreed that it makes sense, and is actually done, to customize these files (or maybe rather, to add customization files in these directories, see below). However, the bug was closed with "XKB files have been moved into /usr/share/X11/xkb, so I am closing this bug". I guess this might be because Debian simply followed an upstream change. Which is an explanation, but not a good reason. What is the consequence of this bug? - In my case, it is that my old setup stopped producing my customized keyboard layout because the files that I added in /etc/ were not found. I fear this will happen to quite a lot of people upgrading from older versions (both sarge and xorg on sarge-backports). - In extreme cases, it might have the consequence that people are not able to log in, because some keys they need for their username or password are not available with the resulting keyboard layout. (And the keyboard layout on the console might never have provided them). - Well, and generally it's a policy violation to ship configuration files in /usr/share. What are possible approaches to solve this bug? 1) move (most of) xkb-data's files back to /etc. The problem here is that if sarge's dpkg is used, this will lead to loads of "created by you or a script" messages. Which can be circumvented by either a "Pre-Depends: dpkg (>=1.1321)" (something you want to avoid) or by removing files with matching md5sums in /var/lib/dpkg/info. Unfortunately, the second approach leads to "conffile has been deleted" prompts when etch's dpkg is used (see #346282). 2) State that - the files in /usr/share/X11/xkb/ represent particular configuration choices, selected by settings in xorg.conf, and are not meant to be configured, but that - it must be possible to *add* new layouts locally. In terms of implementation, this would mean that some tool would have to merge the contents of /usr/share/X11/xkb and *new* files in /etc/X11/xkb, and that the executable needs to be changed to load them from the merging place. 3) State that the files in /usr/share/X11/xkb/ represent particular configuration choices, selected by settings in xorg.conf, and are not meant to be configured, not at all, not even by addition. IMHO, this would only be acceptable if a) it is possible to do single key reassignments in xorg.conf (or at other places, like setxkbmap calls in /etc/X11/Xsession{,.d}), and b) there's a really user-oriented documentation about how to do that, if not an upgrade path. With user-oriented I mean that at least anyone who, years ago, was able to change one of the lines in, say, /etc/X11/xkb/symbols/pc/us, to suit their needs, will be guided to achieve a similar effect with xorg.conf. README.config.gz is not sufficient, since it doesn't talk at all about key remappings, only choosing between existing options. Ideally even someone who got the changed file from a friend would be able to do it. 4) State that I am talking rubish^W^W^W^W^W^W not included here. Regards, Frank -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (99, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- no debconf information -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)