Red Hat Bugzilla – Bug 173384
files end up under /usr/include/X11 symlink
Last modified: 2014-03-16 22:56:54 EDT
Description of problem:
Previously, /usr/include/X11 was a symlink (in xorg-x11-devel)
Now it is a directory (in libX11-devel, etc.)
However, after upgrading to modular X, all the include
files are still in /usr/X11R6/include/X11, because they followed
the /usr/include/X11 symlink.
Version-Release number of selected component (if applicable):
Not sure how fixable this is with current rpm behavior.
Similarly for /usr/lib/X11.
Also on my system, app-defaults, lbxproxy, proxymngr, and rstart under
/usr/lib/X11 were symlinks to the respective directories under /etc/X11.
Ugh, this is rather horrible.
I'm exploring possible solutions right now. If anyone has any suggestions,
please paste ideas in the bug report. My thoughts so far are the following
- Add "Conflicts: filesystem < 2.3.6-1" to every package that contains files
or dirs in /usr/lib/X11 or /usr/include/X11. Also ensure that every
package that puts files in there, has a "Requires: filesystem > 2.3.6-1"
- Add %pre scripts to all of the packages affected, which remove the symlink.
- Some whacky %trigger scripting that I'd really rather avoid like the
The odd thing, is that I've upgraded 2 systems locally to modular X while
developing the packages, and have not encountered this problem at all. My
libs/includes are where they are expected to be. How's that for odd!
Of course, I installed using rpm by hand, not using yum or whatever, so
this could be a package ordering issue perhaps, or even a yum bug.
This one wins the cake for worst "Oh my god, no!!!!" bug of the week.
Well, filesystem (afaik) never shipped usr/include/X11. So, the conflict won't
work for that.
Will have to play some more to see what's possible to fix this.
XFree86-devel and xorg-x11-devel provide the include dir symlink.
After talking with jeremy, jbj, and a half dozen other people, including
Debian and Ubuntu developers, a number of us drew conclusion that the
way Debian/Ubuntu and other distros are doing it seems to be the safest
way of all options available, which is to create a pseudo package which
takes care of ensuring the symlink is replaced by a real dir during
preinstall, and then having all packages that install files into these
dirs Requires(pre) the pseudopackage.
The new package is named "xorg-x11-filesystem", and is now built into
dist-fc5-HEAD. Preliminary testing so far shows no problems, however
it will require much more testing to determine wether there are additional
issues yet unresolved.
I toyed a bit and have to blame myself for it...
Worst case scenario:
Someone like me had modular X installed but not xorg-x11-xbitmaps. If this
person installs this package today it pulls xorg-x11-filesystem which simply
removes the symlinks and replaces them by empty directories. Everything that was
installed into the symlinked dirs before is "lost" now...
Example on my system:
[frank@notebook /]$ ls /usr/X11R6/lib/X11/rgb.txt
[frank@notebook /]$ rpm -qf /usr/X11R6/lib/X11/rgb.txt
file /usr/X11R6/lib/X11/rgb.txt is not owned by any package
[frank@notebook /]$ rpm -qf /usr/lib/X11/rgb.txt
[frank@notebook /]$ ls /usr/lib/X11/rgb.txt
ls: /usr/lib/X11/rgb.txt: No such file or directory
(In reply to comment #6)
> I toyed a bit and have to blame myself for it...
> Worst case scenario:
> Someone like me had modular X installed but not xorg-x11-xbitmaps. If this
> person installs this package today it pulls xorg-x11-filesystem which simply
> removes the symlinks and replaces them by empty directories. Everything that was
> installed into the symlinked dirs before is "lost" now...
Yes, this is a known caveat of the solution. However it only affects
rawhide -> rawhide upgrades, which are never guaranteed to work properly.
Another way of describing the situation, is "this is a casualty of the
development cycle". ;o)
Ok, so rawhide eats its young and uses bar-b-que sauce with jalapenos and
I too have been bit by the "gee lets install xorg-x11-xbitmaps" problem. What
is the best way to fix it. Manually move the files in
/usr/X11R6/[include|lib|share|man|bin] to the corresponding correct
/usr/[whatever] and make symlinks back to /usr/X11R6 ?? Or force a reload of
the new xorg-x11 packages?
(In reply to comment #8)
> Ok, so rawhide eats its young and uses bar-b-que sauce with jalapenos and
> belches afterwards.
> I too have been bit by the "gee lets install xorg-x11-xbitmaps" problem. What
> is the best way to fix it. Manually move the files in
> /usr/X11R6/[include|lib|share|man|bin] to the corresponding correct
> /usr/[whatever] and make symlinks back to /usr/X11R6 ?? Or force a reload of
> the new xorg-x11 packages?
The best way to fix it, is to do a fresh OS install after all of our packages
are fixed. Right now about 2/3 of the affected non-library packages are
fixed, and the rest should be by the end of the week (including libs).
If you want to manually fix it, uninstall all modular X packages, then
manually install xorg-x11-filesystem and deps. Then reinstall all modular
X packages. This will fry openmotif if it is installed, so it'll need to
be reinstalled. There might be other problems too.
Generally speaking, by next Monday, the problem should be resolved to the
point where an FC4->RAWHIDE upgrade works with as few filesystem conflict
problems as possible, unless some new surprises surface. Even in this
case, there can be some unwanted but unavoidable side effects of package
poop left overs.
Part of this problem should be resolved now with the following packages installed:
xorg-x11-filesystem >= 0.99.2-3
xorg-x11-bitmaps >= 0.99.1-4
IMPORTANT NOTE: As mentioned above, there is a caveat to this solution,
which is that packages that have installed their files into X.Org owned
directories, while there was a symlink in the path, will now have to
be reinstalled. There may be rpm installed files left behind afterward
as well. Such is rawhide...
Setting status to "RAWHIDE"
I seem to have forgotten to set the status to "RAWHIDE" as mentioned above. :)
Anyhow, this is fixed now for a while in rawhide. Upgrades from Fedora Core
4 and earlier to Fedora Core 5test2 when it is released, should no longer
encounter this problem.
Upgrades from any modular X builds prior to X11R7 RC4 hitting rawhide over
the last week or so, to current RC4 rpms may or may not work depending on
various factors. This is a caveat of rawhide development which is
unfortunately not workaroundable.
If anyone experiences similar problems after upgrading, just re-upgrade
again or uninstall and reinstall the X packages, and everything should