The new X.org X11 implementation, has now been put in rawhide (was

Mike A. Harris mharris at redhat.com
Thu Mar 18 03:58:11 UTC 2004


On Wed, 17 Mar 2004 netopml at newview.com wrote:

>mharris at redhat.com ("Mike A. Harris") writes:
>> I look forward to hearing people's good/bad success/failure 
>> reports, and any problems that arise being filed in bugzilla with 
>> as many details as possible.
>
>I will bugzilla the following later (against which package?) but so far,
>the upgrade on 2 computers (a desktop and a laptop) was pretty easy.
>
>I had conflicts with openoffice and ttmkfdir and fonts-ja:
>        XFree86-font-utils < 4.2.99.2-0.20021126.3 conflicts with ttmkfdir-3.0.9-10

This one is fixed in 4.2.99.2-0.20021126.5 already.

>        XFree86 is needed by (installed) openoffice.org-1.1.0-30

That's an openoffice package bug, which should be fixed in the 
next openoffice update.

>        XFree86-75dpi-fonts is needed by (installed) fonts-ja-8.0-11

Fixed in 4.2.99.2-0.20021126.5 already.


>No big deal. I ran rpm with --nodeps
>
>But after it was done, the /usr/X11R6/lib was gone from /etc/ld.so.conf so
>I had a problem loading dynamic libraries meaning X wouldn't start. I put
>it back there, ran ldconfig and I was almost back in business except I had
>to restart xfs (service xfs restart, I guess the post install in the rpm
>should do that).

That is actually a bug in XFree86-libs postun script, which
removes /usr/X11R6/%{lib} from ld.so.conf.  There is a race
condition.  Since the bug is in the XFree86-libs package already 
installed on the system, there's no way to fix the broken script 
itself, so the /usr/X11R6/%{lib} will always end up getting 
removed.

This issue is already reported in bugzilla at:

	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118448

I'm not sure how to work around this problem 100%, but I talked 
with some other people and currently what I've done, is I've 
removed the offending code from the -libs postun of the new 
package (which doesn't help us for the existing problem, but 
ensures it wont happen in the future), and I've added a %pre 
section to each of the 3 library subpackages which attempt to add 
the dir to ld.so.conf if it doesn't already exist in there.

If that doesn't fix the problem, the only other thing I can think 
of to try is a trigger.  Triggers generally break more than they 
fix, and do so in a very nasty way which itself is very unfixable 
if you get a bug in your trigger script.  As such I'd like to 
avoid triggers if at all possible.

If anyone has any other suggestions for ideas of how to fix this 
problem, feel free to suggest them in the above bug report, and 
I'll try to investigate.

Worst case scenario is that we end up biting our tongue and 
having to rely on anaconda to fix things up.  That's only if it 
can't be fixed in xorg-x11 packaging itself, which isn't 100% 
clear yet.

Thanks for the feedback!
TTYL

-- 
Mike A. Harris       ftp://people.redhat.com/mharris
OS Systems Engineer - X.org X11 maintainer - Red Hat





More information about the fedora-test-list mailing list