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 a link. 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): 4.3.0 How reproducible: 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 postinstall fails. Actual results: 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. Expected results: 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. Additional info:
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 rpm-list 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 ***