Bug 118448 (xorg-ldso)
Summary: | Upgrading to xorg-x11 removes /usr/X11R6/lib from ld.so.conf | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Bill Nottingham <notting> |
Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | barryn, jfwalton, jochen, linux_dave, mattdm, mgalgoci, oliva, rvokal |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-03-24 08:23:56 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Description
Bill Nottingham
2004-03-16 19:59:44 UTC
Which NVRE? 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. .3 of xorg. Either -62 or -63 of XFree86 (the machine's been wiped since then.) * Wed Mar 17 2004 Mike A. Harris <mharris> 0.0.6.6-0.0.2004_03_11.6 - Added new rpm pre scripts for the libs, Mesa-libGL, and Mesa-libGLU packages which add _x11libdir to ld.so.conf if it is missing, and then run ldconfig, 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 xorg-x11, 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 XFree86 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 spec file in the package Release field. Graciously stolen from the kernel spec file. This is currently unused, but may be used in the future. nice formatting bugzilla Hmmm -- maybe (also) put the code to fix this in the x startup scripts? (Like startx and prefdm.) That's sick, i know, but.... A few hours ago I tried upgrading from XFree86-4.3.0-63 to xorg-x11 0.0.6.6-0.0.2004_03_11.6. 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. 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.
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... 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: http://www.geocrawler.com/archives/3/87/2003/7/0/10575444/ 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. Triggers! :) 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... 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
aspects.
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.
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.) 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.
I just tested the latest patch (attachment 98748 [details]). It didn't improve anything. So, unless anyone can come up with something better, I'd like to see attachment 98747 [details] applied to the xorg-x11 spec file. *** Bug 118818 has been marked as a duplicate of this bug. *** I've given this bug report the bugzilla bug alias "xorg-ldso" for easier closing of duplicates. *** Bug 118993 has been marked as a duplicate of this bug. *** *** Bug 118851 has been marked as a duplicate of this bug. *** Fixed in rawhide, in xorg-x11-0.0.6.6-0.0.2004_03_11.8, which will be available tomorrow sometime. |