Bug 245827 - xorg-x11-fonts provided links in /etc/X11/fontpath.d/ are absolute
Summary: xorg-x11-fonts provided links in /etc/X11/fontpath.d/ are absolute
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-fonts
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-06-26 21:38 UTC by Michal Jaegermann
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-07-10 13:45:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michal Jaegermann 2007-06-26 21:38:16 UTC
Description of problem:

Various font packages create absolute links in /etc/X11/fontpath.d/
like
  xorg-x11-fonts-misc:unscaled:pri=10 -> /usr/share/X11/fonts/misc:unscaled
instead of linking to
   ../../../usr/share/X11/fonts/misc:unscaled
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):
xorg-x11-fonts-7.2-1.fc8

Comment 1 Adam Jackson 2007-06-28 22:10:05 UTC
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 22:49:45 UTC
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 19:01:24 UTC
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 20:41:07 UTC
> 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 13:45:45 UTC
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.