Version-Release number of selected component (if applicable):
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
Thanks for the report.
Fixed in xorg-x11-6.8.2-20 and later, will be in rawhide soon.
*** 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.