Bug 36757 - subpackag install creates invalid symlinks
subpackag install creates invalid symlinks
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-20 01:09 EDT by mw
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-20 14:08:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description mw 2001-04-20 01:09:58 EDT
For example, installing the XFree86-xfs package,  from the directory
/usr/X11R6/lib/X11, I see

lrwxrwxrwx    1 root     root           24 Apr 19 23:28 fs ->
../../../.././etc/X11/fs

so you see, in the last  past component right before `etc' there is only a
single dot:

/./etc/.....

This gives me errors

# service xfs start
Starting xfs: xfs error: CONFIG: can't open configuration file
"/usr/X11R6/lib/X11/fs/config"
xfs error: fatal: couldn't read config file

# ls ../../../.././etc/X11/fs
/bin/ls: ../../../.././etc/X11/fs: No such file or directory

All is well, if I use cd instead of ls:

# cd ../../../.././etc/X11/fs; pwd
/etc/X11/fs

This must be because cd is a shell builtin, hence understands how to follow
symlinks (/usr/XFree86 is a symlink on my system) 

Here is the full list

# ls -l |awk ' /\/\.\/etc/ { print $NF }'
../../../.././etc/X11/fs
../../../.././etc/X11/twm
../../../.././etc/X11/xdm
../../../.././etc/X11/xinit
../../../.././etc/X11/xsm

I could not find the script making up these symlinks in the spec file, so I
just ran

cd /usr/X11R6/lib/X11
for i in fs twm xdm xinit xsm; do
     ln -sf ../../../../../etc/X11/$i .
done
Comment 1 Mike A. Harris 2001-04-20 02:19:41 EDT
My system has the same links as you point out above.  However, these
links although messy are not wrong per se.  Relative pathnames can be
very strange and still work.  ie:

cd /usr/X11R6/lib
cd ../lib/../lib/../../X11R6/bin/../../../home/mharris
Odd symlinks work in the same manner.  The ../../../.././etc/blah is
equivalent to ../../../../etc/blah as the "." gets ignored.

Currently without knowing better, I think they should be fixed just to
be clean, however before doing so I will need to determine what exactly
is creating them in this manner, and determine if it is doing so for
good reason or not.

Are you using *ALL* of the Red Hat Linux RPM's or are you mix and matching
with older RPM's or other distro RPM's of XFree86?  Are you using any
homemade parts of XFree?
Comment 2 mw 2001-04-20 14:08:43 EDT
While my system is a mix of 7.0 and 7.1 components due to my not yet successful
upgrade attempt, the XFree86 is pure 7.1.  And I did  reinstall XFree86-xfs just
to see, and it does create these "bad" symlinks again.  

Here is what I have

$ rpm -qa|egrep -i 'xfree|^xconf'
XFree86-ISO8859-7-Type1-fonts-1.0-9
XFree86-cyrillic-fonts-4.0.3-5
XFree86-ISO8859-7-100dpi-fonts-1.0-9
XFree86-KOI8-R-75dpi-fonts-1.0-6
Xconfigurator-4.9.27-1
XFree86-ISO8859-2-75dpi-fonts-4.0.3-5
XFree86-doc-4.0.3-5
XFree86-ISO8859-7-75dpi-fonts-1.0-9
XFree86-ISO8859-9-75dpi-fonts-2.1.2-16
XFree86-SVGA-3.3.6-35
XFree86-ISO8859-2-1.0-12
XFree86-100dpi-fonts-4.0.3-5
XFree86-tools-4.0.3-5
XFree86-KOI8-R-100dpi-fonts-1.0-6
XFree86-100dpi-fonts-4.0.3-5
XFree86-ISO8859-2-Type1-fonts-4.0.3-5
XFree86-jpfonts-2.0-12
XFree86-4.0.3-5
XFree86-ISO8859-7-Type1-fonts-1.0-9
XFree86-twm-4.0.3-5
XFree86-xfs-4.0.3-5
XFree86-KOI8-R-1.0-6
XFree86-libs-4.0.3-5
XFree86-75dpi-fonts-4.0.3-5
XFree86-ISO8859-9-75dpi-fonts-2.1.2-16
XFree86-75dpi-fonts-4.0.3-5
XFree86-VGA16-3.3.6-35
XFree86-libs-4.0.3-5
XFree86-ISO8859-7-1.0-9
XFree86-ISO8859-9-100dpi-fonts-2.1.2-16
XFree86-KOI8-R-100dpi-fonts-1.0-6
XFree86-xdm-4.0.3-5
XFree86-ISO8859-9-100dpi-fonts-2.1.2-16
XFree86-ISO8859-7-75dpi-fonts-1.0-9
XFree86-KOI8-R-75dpi-fonts-1.0-6
XFree86-ISO8859-2-100dpi-fonts-4.0.3-5
XFree86-devel-4.0.3-5
XFree86-ISO8859-9-2.1.2-16
XFree86-xf86cfg-4.0.3-5

It seems the problem is more general in nature.  Namely, I think in some
situations relative symlinks are not really a good idea (while I understand that
RH's upgrade requires them).  Indeed, what if I move a directory with rel
symlinks in it to a different directory so that it will now reside one or more
levels *deeper* from / ? 

For example:

# mkdir  -p /1 /2/3 /deeper
# ln -s ../2 /1
# ls -d /1/2/3
/1/2/3/
# mv /1 /deeper
# ln -s /deeper/1 /
# ls -d /1/2/3
/bin/ls: /1/2/3: No such file or directory

Now on my system, I moved /usr/X11R6/ to /disk02/usr/X11R6/---one level deeper
than it originally was.
Comment 3 Mike A. Harris 2001-08-13 09:26:52 EDT
The relative symlinks are not 'required' by anything.  There
are problems with using absolute links, and problems with using
relative links.  We've weighed the strengths and weaknesses of
both approaches and have decided that the merits of relative
links outweight the merits of absolute links.

While changing that is not open for discussion, the symlink
problem with the /./ in it (just a cosmetic problem) has been
brought up with XFree86 team and a solution found.  The current
XFree86 head branch of CVS should build these links properly
now.  This will appear in some future release.  I'm closing the
report now as WONTFIX, however it will appear fixed in the future.

"FIXEDUPSTREAM" isn't here...  ;o)

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