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.