Version-Release number of selected component (if applicable): xorg-x11-6.8.1-12.FC3.21 Description of problem: In attempting to solve bug 120858, the XkbRules line is removed from /etc/X11/xorg.conf in the %pre section of xorg-x1's specfile. However, the description in the comment of what should be done # - Remove Option "XkbRules" "xfree86" and the later comment and actual command # Remove any Options "XkbRules" lines that may be present perl -p -i -e 's/^.*Option.*"XkbRules".*\n$//gi' $configfile are two quite different things. While the intention is to remove any references to the xfree86 rules, actually any rule at all is deleted. In our network, this creates mayhem. We have created our own rules, and xorg.conf reads Option "XkbRules" "local" which is essential for our keyboards to work but is erased every time the xorg-x11 package is upgraded. The relevant line in the %pre section of the specfile should read perl -p -i -e 's/^.*Option.*"XkbRules".*"xfree86".*\n$//gi' $configfile Or, if you want to get rid of both xfree86 and xorg rules, make two lines. But please do not destroy peoples intentional configurations!
There are a few problems. Initially, the "Xorg" server changed the name of it's rules file very appropriately to "xorg". There was a tonne of broken software in the wild which hard coded the Xkb rules filename to "xfree86". Since xorg did not supply a "xfree86" rules file, the software that assumed the name would always be "xfree86" broke. Of course this is a flaw of the software, not a flaw of Xorg. What's worse, is that for whatever reason, our config tools hard coded the xkb rules file as "xfree86" in the X server config file, when instead, we should not have been putting this information into the config file at all. This caused a lot of problems, and so we changed our tools to no longer put the Xkb rules line in the config file, which makes sense. To solve the problem completely, we modified our upgrade procedure to remove the line from existing configs as well. Since this filename will be changing in the future (probably to 'base'), this problem will recur again in the future, and there are probably applications out there that still hardcode wither xfree86 or xorg or both, which is also unfortunate, as they will break again. ;o) So, we definitely will want to make sure the config file does not specify "xfree86", and "xorg" is redundant, so it can be parsed for manually as well. This will also have the effect of making the renaming to "base" in the future smooth also (assuming it does happen upstream as has been discussed in the past). We'll review this again for Fedora Core 4 development in the near future, and update the bug report when any changes have been made. Once that happens, assuming no regressions are reported, we will also consider backporting the changes in future FC3/RHEL4 updates as well. Thanks for the report.
Fixed in xorg-x11-6.8.2-20 and later, will be in rawhide soon. Thanks.
*** Bug 152945 has been marked as a duplicate of this bug. ***
From User-Agent: XML-RPC xorg-x11-6.8.2-1.FC3.45 has been pushed for FC3, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.