Bug 88857
Summary: | xkb directory is reversed compared to XFree source install | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Walter Francis <wally> |
Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
Status: | CLOSED DUPLICATE | QA Contact: | David Lawrence <dkl> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 9 | CC: | xgl-maint |
Target Milestone: | --- | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-04-20 13:04:52 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Walter Francis
2003-04-15 00:51:57 UTC
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. |