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): libX11-devel-0.99.3-3, etc. 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 possibilities: - 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" in it. or - Add %pre scripts to all of the packages affected, which remove the symlink. or - Some whacky %trigger scripting that I'd really rather avoid like the plague. 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 /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 xorg-x11-server-utils-0.99.2-3 [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 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? Thanks.
(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. > Thanks. Part of this problem should be resolved now with the following packages installed: xorg-x11-filesystem >= 0.99.2-3 filesystem-2.3.7-1 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 work properly.