Bug 245827 - xorg-x11-fonts provided links in /etc/X11/fontpath.d/ are absolute
xorg-x11-fonts provided links in /etc/X11/fontpath.d/ are absolute
Product: Fedora
Classification: Fedora
Component: xorg-x11-fonts (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-06-26 17:38 EDT by Michal Jaegermann
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-10 09:45:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2007-06-26 17:38:16 EDT
Description of problem:

Various font packages create absolute links in /etc/X11/fontpath.d/
  xorg-x11-fonts-misc:unscaled:pri=10 -> /usr/share/X11/fonts/misc:unscaled
instead of linking to
Mount that over NFS on some subdirectory, or like anaconda does
that during updates, and these will point into wrong places.  Is that
really intended?

Besides 'rpmlint' is likely unhappy with that too. :-)

Version-Release number of selected component (if applicable):
Comment 1 Adam Jackson 2007-06-28 18:10:05 EDT
What, exactly, would be the point of using relative symlinks, given that the
only directory they have in common is / ?
Comment 2 Michal Jaegermann 2007-06-28 18:49:45 EDT
What, exactly, would be the point of using absolute symlinks. given
that after mounting all of that on some subdirectory they will
be pointing into wrong, possibly non-existent, locations?

Probably not that important most of the time, with a possible
exception of those few where that would handy, but what are
costs?  True, up to now paths listed in fs/config were absolute.
Comment 3 Adam Jackson 2007-07-05 15:01:24 EDT
If you installed your fonts into a directory that you then unmounted, you've
pretty much already asked for it to be broken.  Relative symlinks aren't going
to help you there.

And they _have_ to be symlinks because that's how the code works.  It calls
readlink() to find the location, priority, and any other options.

I guess I can see the point about anaconda installing off into space if you're
upgrading and your runtime /usr is on NFS, but I suspect that's a problem with
every other package that installs into /usr.  Do we get that case right at all?
Comment 4 Michal Jaegermann 2007-07-05 16:41:07 EDT
> but I suspect that's a problem with
> every other package that installs into /usr.

I am not sure about "every other".  More and more rpm created
links are relative and some were that way for a long time.
I had an impression that rpmlint will complain otherwise and
especially /usr/share/ should be ready to be mountable over NFS.
OTOH those links in question are used when a system is running
and not when you are upgrading it, right?

All in all apparently not the most important issue but I thought
that I better put a note in bugzilla anyway.
Comment 5 Adam Jackson 2007-07-10 09:45:45 EDT
If we get an actual policy about symbolic links, then I'll be happy to revisit
this.  But at the moment, we don't, and (after light discussion with the
installer team) anaconda should be restoring as much of your normal filesystem
state as possible for upgrades, so I don't think it's even an issue there.

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