From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031009 Description of problem: The installation of Fedora Core test3 fails on installing XFree86-4.3.0, at which point the install refuses to go on, and asks you to reboot. The failure comes from the RPM unpacking, and doing it by hand afterwards shows: error: unpacking of archive failed on file /etc/X11/xkb: cpio: rename failed - Is a directory which is indeed true: /etc/X11/xkb is a directory. This machine had an updated XFree86 from CVS sources, which is likely the cause for the confusion. I assume a clean RH-9 upgrade does not show the problem. Arguably, it's my own fault. Fair enough. Equally arguably the upgrade process is just too fragile. You make the call. Version-Release number of selected component (if applicable): XFree86-4.3.0-37.i386 How reproducible: Always Steps to Reproduce: 1. Start with RH-9 2. compile/install XFree86 from CVS, making /etc/X11/xkb a directory 3. Profit! (Actually: "3. Try to install Fedora") A simpler way to reproduce is probably to just take a plain RH-9 install, and do mv /etc/X11/xkb /etc/X11/xkb-link cp -a /etc/X11/xkb-link/ /etc/X11/xkb to make xkb a directory, and then try the Fedora install. Actual Results: Upgrade fails half-way, resulting in a pretty broken system Expected Results: I'd have hoped it would just remove the old xkb directory and happily continued the upgrade with the new contents. Additional info: Why is that thing a symlink in the first place? It causes problems when doing a regular "make install" from X sources.
Ah yes, I haven't had this one reported for quite a while. ;o) It only bites people who install XFree86 from source on top of the rpm installed XFree86, and then later try to upgrade the OS, or just XFree86 using rpm. The problem is caused due to a historical mistake someone made when packaging XFree86 a long time ago (before I got my Fedora) where the xkb files were left in /usr/X11R6/lib/X11/xkb, but a symlink made in /etc/X11 pointing to them. XFree86 wants to have /etc/X11/xkb as a directory IIRC, and have the symlink pointing the other way. The reason this breaks is because rpm can't replace a directory with a symbolic link for various technical reasons. It's very difficult if not rather impossible to get rpm to be able to handle those types of unfortunate situations, and there are a few packages in the distribution with equal oddity. Our /etc/rc.d/* stuff is another example of where we couldn't move stuff, although that doesn't actually harm anything or get in the way, and is also LSB/FHS compliant still. ;o) It's possible to create a hack using rpm postinstall scripts to do this, however there are pitfalls, since it basically involves moving directories around, and if the target doesn't contain enough disk free space, bad things could happen. There are other issues such as other packages having possibly installed files in the directories, and other issues. If I ignore the generalized problem though of RPM not supporting what is needed, and just look at it from the view of solving this one problem, with disk sizes as big as they are, if I did do the ugly hack fix nowadays, the number of people who get bit from out of disk space or some other similar issue would probably be relatively small, and one might argue the number of people compiling X from source is potentially larger to justify the ugly hack. I'm thinking of something like the following: - calculate disk space consumption of installed directory that will be moved - if destination partition has that much (plus a small amount), or more space on it: - remove symlink - move the directory to the new location - create symlink pointing in reverse from original location The trick is to handle all of the error scenarios, which could be tricky Bill, assuming this would be a 4.4.0 packaging change, what do you think of this kind of one time hack?
If you're packaging files under /etc/X11/xkb, you don't need to worry about space, it will get calculated as part of the normal RPM space calculations, as I recall. (It's all of about 2.5MB in any case.) %pre rm -rf /usr/X11R6/lib/X11/xkb will solve the upgrade case for converting that directory to a symlink. If you want to proof against having X installed in our current packaging, you *could* have: %pre [ -d /etc/X11/xkb ] && rm -rf /etc/X11/xkb
That might be acceptable, however if a user has added any custom edited xkb files, we'd be straight out deleting them. Being in /etc/X11/xkb, users might expect this is valid to modify/change/edit/add stuff to, and expect it to not be destroyed on upgrade. A reasonable assumption IMHO, at least for file additions. Perhaps the following is cleaner: %pre # Switch the xkb directory and symlink around for better compatibility with # XFree86.org defaults and general sanity, without blowing away user created # xkb files. if [ -l /etc/X11/xkb -a -d /usr/X11R6/lib/X11/xkb ];then rm -f /etc/X11/xkb && \ mv -f /usr/X11R6/lib/X11/xkb /etc/X11/xkb && \ ln -sf ../../../../etc/X11/xkb /usr/X11R6/lib/X11/xkb fi Does this seem sane? Once I branch the specfile for 4.3.99.x/4.4.0, I'll be making rather drastic changes, which would be a good time to do this change too. I'm also going to get rid of the unnecessary trigger scripts as we no longer ship or support 3.3.6, and those triggers are only needed for XFree86 distros shipping both 3.3.6 and 4.x to coexist cleanly. Lots of other hacks and kludge can go away too, to make room for newer hacks and kludge. ;o)
The problem with that as a %pre is that all the rpm transaction gunk will have run in the premise that /etc/X11/xkb is a symlink, and /usr/X11R6/lib/X11/xkb is a directory. So, it might still choke on 'removal' of the old package when its contents aren't what they were at the start of the package install.
Ugh. Yes that's right. Hmm. I'll have to do some experiments during our next cycle on my local system and see if I can come up with some kind of clean solution of any sort that can handle this acceptably, then test it for correctness before unleashing it on the unsuspecting masses.
We've discussed this internally now, and have decided we'd really like to tackle this longstanding ugly Red Hat goofup for once and for all, but to do so at a major X development cycle, rather than within a stable branch. As such, we are targetting the risk-factor of fixing this, for the X11R7 upstream release (or whichever the first modular release ends up becoming). It will be nice to get rid of this uglyness. ;)
yes, I found the root of the problem on spec session files we have %{_x11datadir}/X11/xkb/* /etc/X11/xkb but should be %{_x11datadir}/X11/xkb /etc/X11/xkb/* why? because xorg now put real dir on /etc/X11/xkb and entry on spec "ln -sf ../..%{_x11datadir}/X11/xkb $RPM_BUILD_ROOT/etc/X11" can/should be deleted happens the same thing with app-defaults now should be : %dir %{_x11datadir}/X11/app-defaults %config /etc/X11/app-defaults/*
well, by default xorg defines UseConfDirForXkb and UseConfDirForAppDefaults to yes but in spec you got: /* FIXME: Other distros set these to yes. Should we do this soon too? */ #define UseConfDirForXkb NO #define UseConfDirForAppDefaults NO so if we delete this lines on spec my last comment is true.
The problem, is that rpm can not replace a directory with a symlink, because the directory contains files already, and may contain files from some other rpm package also. So if you make the changes suggested above, and try to do "rpm -Uvh *.rpm" with newly generated rpms, it will explode. There is no simple solution to the problem without taking risks. You can use "mv" in rpm post scripts to remove the symlink, move the dir to where the symlink used to be, and then make the new symlink so the symlink and dir are reversed, but if the filesystem which the directory is being moved to does not contain enough space to hold the directory, it will cause a failure which results in a very big mess. There are various other corner cases which can really break the system pretty badly and have no easy recovery path. The suggestions in comments #11 and 12 do not solve this underlying problem at all. If it were as simple as making the suggested changes, we'd have done it 4 years ago. ;o) We have an opportunity to possibly fix this with X11R7, because there are some upstream changes that might happen which would allow us to sidestep the problem and fix it in a different way that is not really possible currently. I wont get into the details right now, but as we near X11R7 being included in rawhide, I'll update this with more info. In the mean time, anyone compiling Xorg or XFree86 from source should do: #define ProjectRoot /usr/local/X11R6 #define NothingOutsideProjectRoot #define EtcX11Directory ProjectRoot/etc This will cause your custom X installation to be completely contained within /usr/local/X11R6, and you can then use LD_LIBRARY_PATH to override library dirs, and PATH to override bin dirs, etc. which is a nifty workaround. Using this technique and a few other tricks, several X11 installations can coexist. Hope this helps.
*** Bug 88857 has been marked as a duplicate of this bug. ***
*** Bug 161349 has been marked as a duplicate of this bug. ***
Problem now resolved in Fedora development (slated for FC5) with modular X.Org X11R7.0. The new release has the xkb files contained in /usr/share now, so both the old locations are inactive and no longer conflict. The side effect of that is totally avoiding having to work around the rpm deficiency that can't replace dirs with symlinks or vice versa. Setting status to "RAWHIDE".