Description of problem:
In RH 8 and once again in RH 9 I found myself with the installer bombing out and
wanting to reboot saying there is a problem with XFree RPM, could be this or
that. Luckily I remembered the problem last time.
Red Hat makes /usr/X11R6/lib/xkb a directory with the relevant files in it, and
/etc/X11/xkb links to it.
Official XFree86 source installation has it /etc/X11/xkb is the directory and
/usr/X11R6/lib/xkb links to it.
This causes RPM to barf because /etc/X11/kxb is a directory and it is expecting
Why are these dirs/links reversed? Doesn't make any sense, and it just causes
trouble for the RPM later. If there is some REALLY good reason for this, why
not code the postinstall script to check for this condition? I know you can't
support mixed rpm/source installs, but this is a very simple problem.
Version-Release number of selected component (if applicable):
Every time if you have upgraded XFree from source.
Steps to Reproduce:
1.Install XFree86 from source from xfree86.org on a prior version of Red Hat
2.Run installation, when it gets to upgrade XFree86 it bombs out because the
error: /etc/X11/xkb is not a directory. This is from RPM. If I mv /etc/X11/kxb
and /usr/X11R6/lib/xkb and re-run the rpm upgrade (or the entire install) it
will get past this point without any trouble.
The directory/link NOT be reversed in the first place. Alternatively, have the
postinstall check for this condition and do the right thing and move them out of
the way and continue.
This is a known problem, but it is not easily solveable. RPM can not
replace a directory with a symbolic link, and as such it creates a number
of rather complex problems in order to try and solve this type of issue in
a foolproof way. It's a class of problem that has been something we'd love
to be able to solve in a safe way for many years.
While I do admit that our dir/symlink is backwards, it was due to a mistake
made long ago, and as mentioned above there is no easy way to fix it
currently. It has been on my mind each release though, and I'm going to try
to fix it in the future in some way in rawhide and see what real problems come
up, but it could be messy theoretically - although I wont go into the specific
issues that cause it to be such a tough problem to solve. That is best left
for a discussion on firstname.lastname@example.org if you're more deeply interested in
the problem than what I'm willing to go into in a bug report.
On a separate note, while I acknowledge the problem and do want to fix it,
you should be aware that Red Hat does not in any way support upgrading systems
which have major core system components replaced by end users with custom
components or components installed from source code. So technically what
you are doing is unsupported - however that's not an excuse for the problem
we have in our packaging.
If I could go back 3 or 4 years and slap the person silly who made this
brokenness in the RPM packaging (prior to my employment here), I would
make sure they were appropriately tortured. ;o)
I think this is already reported elsewhere in bugzilla as a thing to
keep an eye on over time, and it is something definitely that I think about
several times per release cycle. I'll leave this open for now nonetheless
to keep it more visible as a reminder of the problem.
Status update: This is an issue that we really should fix at some
point, but is low priority overall. It is something potentially
quite complex to fix and get just right without having long term
side effects for end users upgrading via rpm, as it probably
requires triggers to do right, and they're tricky.
This is something we should review during the first stage of
Fedora Core 4 development, before the first test release.
Setting status to "DEFERRED", with a review target goal of
Fedora Core 4 test1.
*** This bug has been marked as a duplicate of 107383 ***