Bug 118448 (xorg-ldso) - Upgrading to xorg-x11 removes /usr/X11R6/lib from ld.so.conf
Summary: Upgrading to xorg-x11 removes /usr/X11R6/lib from ld.so.conf
Alias: xorg-ldso
Product: Fedora
Classification: Fedora
Component: XFree86
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
: 118851 118993 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-16 19:59 UTC by Bill Nottingham
Modified: 2014-03-17 02:43 UTC (History)
8 users (show)

Clone Of:
Last Closed: 2004-03-24 08:23:56 UTC

Attachments (Terms of Use)
patch to xfs.init to fixup /etc/ld.so.conf after the fact (784 bytes, patch)
2004-03-19 08:45 UTC, Barry K. Nathan
no flags Details | Diff
patch to SPEC file to add triggers (1.14 KB, patch)
2004-03-22 11:59 UTC, Barry K. Nathan
no flags Details | Diff
updated xorg-x11 fix using triggers (1.13 KB, patch)
2004-03-22 14:12 UTC, Barry K. Nathan
no flags Details | Diff
updated triggers patch: "restart" (not "condrestart") xfs (1.13 KB, patch)
2004-03-22 15:46 UTC, Barry K. Nathan
no flags Details | Diff

Description Bill Nottingham 2004-03-16 19:59:44 UTC
It appears to have eaten /usr/X11R6/lib out of /etc/ld.so.conf. So the
library deps are broken.

Comment 1 Mike A. Harris 2004-03-17 19:46:44 UTC
Which NVRE?

Comment 2 Mike A. Harris 2004-03-17 19:51:29 UTC
Actually, what NVRE of XFree86, and if you're upgrading to xorg,
what NVRE of xorg?  ie: a before and after, so I can examine rpm
script interactions.

Comment 3 Bill Nottingham 2004-03-17 20:01:25 UTC
.3 of xorg. Either -62 or -63 of XFree86 (the machine's been wiped
since then.)

Comment 4 Mike A. Harris 2004-03-17 22:06:07 UTC
* Wed Mar 17 2004 Mike A. Harris <mharris@redhat.com>
- Added new rpm pre scripts for the libs, Mesa-libGL, and Mesa-libGLU
  which add _x11libdir to ld.so.conf if it is missing, and then run
  in order to work around a race condition in the
XFree86-libs-4.3.0-64 and
  older XFree86-libs packaging which could cause _x11libdir to be removed
  from ld.so.conf when other packages are still using it, including
  causing upgrades to fail (#118448)
- Removed the offending code from xorg-x11-libs postun script so that this
  problem is not preserved in xorg-x11 packaging.  Also updated our
  packaging in cvs, so future XFree86 erratum for Fedora Core 1 and
other OS
  releases will help to reduce the chances of someone getting hit by this
  upgrade problem.
- Added initial support to spec file for using the CVS Revision of the
  file in the package Release field.  Graciously stolen from the
kernel spec
  file.  This is currently unused, but may be used in the future.

Comment 5 Mike A. Harris 2004-03-17 22:06:40 UTC
nice formatting bugzilla

Comment 6 Matthew Miller 2004-03-18 14:09:17 UTC
Hmmm -- maybe (also) put the code to fix this in the x startup
scripts? (Like startx and prefdm.) That's sick, i know, but....

Comment 7 Barry K. Nathan 2004-03-18 17:08:03 UTC
A few hours ago I tried upgrading from XFree86-4.3.0-63 to xorg-x11 I experienced the ld.so.conf problem anyway,
despite the attempts at a fix.

(Hmmm... is it really a race condition? Maybe I'm wrong, but isn't it
well-defined that, in any given RPM transaction, RPM first installs
all packages and then removes packages? If I'm right, then if it can
be considered a race condition, it's one that deterministically
happens always.)

Matthew, if anyone follows your suggestion, I think it actually needs
to be done in the xfs startup script, not the actual X startup
scripts. That's where the bug first bit me when it hit.

Comment 8 Barry K. Nathan 2004-03-19 08:45:51 UTC
Created attachment 98674 [details]
patch to xfs.init to fixup /etc/ld.so.conf after the fact

This is basically Matthew Miller's sick suggestion implemented in the xfs
startup script. As sick as it is, it may be less sick overall than trying to
fix the entire problem from within the xorg-x11 RPM scripts alone.

Comment 9 Barry K. Nathan 2004-03-19 08:56:12 UTC
OH NO. I just realized that, on my system at least, XFree86-xfs is
causing the same sort of problem as XFree86-libs: after the new
xorg-x11-xfs is in place, the old XFree86-xfs gets removed -- running
"/sbin/chkconfig --del xfs" then removing the xfs user and group!
(Right now xfs is running as root rather than xfs on my system,
because the xfs user and group don't exist. That can't possibly be good.)

Man this is becoming a nightmare! Right now I'm wondering why this
type of stuff didn't happen for previous XFree86->XFree86 upgrades,
even though it's happening for XFree86 -> xorg-x11. I think I need to
read up on RPM a bit...

Comment 10 Barry K. Nathan 2004-03-19 09:36:03 UTC
Ok, I've referred to Red Hat RPM Guide and now I understand what the
h--- is going on.

First, as an aside, here's a reference for my claim that all installs
are run first, then all uninstalls are run afterward:

This means (not counting triggers) *all* of the xorg-x11-* package
scripts will run before the XFree86-* preun/postun scripts kick in.

Right now I'm first going to think about how to fix the xfs problem;
it seems to me that any solution to the xfs problem could apply to the
libs problem but not the other way around.

Comment 11 Bill Nottingham 2004-03-19 16:40:51 UTC
Triggers! :)

Comment 12 Barry K. Nathan 2004-03-19 21:04:11 UTC
Yes, I had to do other stuff last night/this morning, but I was going
to post (in some detail) why I believe triggers are cleaner than the
alternatives (including the sick patch I attached yesterday). Anyway,
that post will have to wait for later...

Comment 13 Barry K. Nathan 2004-03-22 11:59:56 UTC
Created attachment 98745 [details]
patch to SPEC file to add triggers

I think this may be the cleanest way to fix this bug -- both the -xfs and -libs

Note that THIS PATCH IS UNTESTED. It's also my first time writing triggers.
However, I am hoping to test the patch at some point in the next 24 hours.

Comment 14 Barry K. Nathan 2004-03-22 14:12:54 UTC
Created attachment 98747 [details]
updated xorg-x11 fix using triggers

Attachment 98745 [details] works (i.e. I've tested it now, and it fixes both the libs and
xfs problems), but this patch should be better:
+ It avoids dragging an (arguably) unrelated comment into one of the triggers
(by adding a blank line).
+ It actually puts the triggers in the subpackages now, not the main xorg-x11
package (oops).
+ I clarified one of the comments I added in the previous patch.

I haven't tested this patch yet, but I'll try to test it later today. (First I
need to file another packaging-related bug against xorg-x11, although this one
is very minor in comparison.)

Comment 15 Barry K. Nathan 2004-03-22 15:46:13 UTC
Created attachment 98748 [details]
updated triggers patch: "restart" (not "condrestart") xfs

Ok, I tested the latest attachment. It turns out I was a little mistaken about
both of my last two attachments -- neither one leaves xfs running after
installation. *BUT* both of them do fix the problem with xfs not running at
boot time, as well as the problem where the xfs user wouldn't be recreated.
Also, it looks like the comment gets brought into the trigger despite the extra
blank line.

Maybe we should just "restart" rather than "condrestart" xfs. That's what this
latest patch does. I'm going to test this one within the next few hours.

Comment 16 Barry K. Nathan 2004-03-22 16:29:32 UTC
I just tested the latest patch (attachment 98748 [details]). It didn't improve

So, unless anyone can come up with something better, I'd like to see
attachment 98747 [details] applied to the xorg-x11 spec file.

Comment 17 Bill Nottingham 2004-03-23 02:29:23 UTC
*** Bug 118818 has been marked as a duplicate of this bug. ***

Comment 18 Mike A. Harris 2004-03-24 00:49:07 UTC
I've given this bug report the bugzilla bug alias "xorg-ldso" for
easier closing of duplicates.

Comment 19 Mike A. Harris 2004-03-24 01:20:52 UTC
*** Bug 118993 has been marked as a duplicate of this bug. ***

Comment 20 Mike A. Harris 2004-03-24 01:23:06 UTC
*** Bug 118851 has been marked as a duplicate of this bug. ***

Comment 21 Mike A. Harris 2004-03-24 08:23:56 UTC
Fixed in rawhide, in xorg-x11-, which will
be available tomorrow sometime.

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