This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 107383 - XFree86/xorg-x11 upgrade/install fails if X has previously been installed from raw source.
XFree86/xorg-x11 upgrade/install fails if X has previously been installed fro...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
: Triaged
: 88857 161349 (view as bug list)
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2003-10-17 12:30 EDT by Linus Torvalds
Modified: 2007-11-30 17:10 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-06 01:03:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Linus Torvalds 2003-10-17 12:30:06 EDT
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.
Comment 1 Mike A. Harris 2003-10-17 13:12:48 EDT
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?
Comment 2 Bill Nottingham 2003-10-17 15:00:45 EDT
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

Comment 3 Mike A. Harris 2003-10-18 04:45:06 EDT
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)

Comment 4 Bill Nottingham 2003-10-20 00:01:18 EDT
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.
Comment 5 Mike A. Harris 2003-10-20 04:26:31 EDT
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.
Comment 7 Mike A. Harris 2004-12-22 10:42:12 EST
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. ;)
Comment 11 Sergio Monteiro Basto 2005-04-19 14:50:14 EDT
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/*
Comment 12 Sergio Monteiro Basto 2005-04-19 16:00:43 EDT
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.

Comment 13 Mike A. Harris 2005-04-19 17:13:09 EDT
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.
Comment 14 Mike A. Harris 2005-04-20 09:05:04 EDT
*** Bug 88857 has been marked as a duplicate of this bug. ***
Comment 15 Mike A. Harris 2005-08-30 03:57:21 EDT
*** Bug 161349 has been marked as a duplicate of this bug. ***
Comment 16 Mike A. Harris 2006-02-06 01:03:11 EST
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".

Note You need to log in before you can comment on or make changes to this bug.