Savage DRI broken in modular X

[Mike A. Harris]

Joachim Frieben wrote:

> I can't follow here. The worst thing to happen is that the symlink
> might not be used anymore, once the "Mesa" library gets fixed to
> look up in "/usr/lib/dri". The directory "/usr/lib/dri" is unlikely
> to change some time soon, and even if it did, the orphaned link
> could hardly cause any problem. Given "DRI" up and running today,
> this is an acceptable trade-off and allowed furthermore to
> successfully identify the bug. Anyway, thanks for your advice.

The new packages will be installed *into* the symlink that is present,
however rpm does not store where they are _actually_ going to land,
but rather the paths where they were supposed to land if the
symlink wasn't there.  This can end up with a race condition in
rpm transaction sort potentially.

The whole /usr/lib/X11 symlink problem is caused by this same issue,
and we're still working out how to solve that.  In that instance
however, we're responsible for the symlink, so need/want to fix
it.  For symlinks that were smashed into the system by someone else,
if it causes the system to break - you get to keep both pieces.  ;o)


> It's not that ridiculous. "Mathematica" for example has "Open
> Motif 2.1.30" compiled in statically. After fixing the font
> problem - the new ISO 10646 fonts lead to empty buttons what I
> fixed by installing the ISO 8859 fonts afterwards - I am now
> facing error messages of the kind:
> 
> "Warning: translation table syntax error: Unknown keysym name:
> osfBeginLine Warning: translation table syntax error: %s" ...
> 
> For backwards compatibility, Red Hat still provides packages
> like: "compat-libstdc++-296-2.96", "compat-openldap-2.3.11"
> and many others. This made me think of the possible need to
> provide older applications with some legacy stuff.

In a previous email I mentioned we would provide some backward
compatibility where it is deemed needed.  I hope I wasn't unclear
about that.  What I am saying right now however, is that such
backward compatibility is _intentionally_ not going into rawhide
right /now/, because we want to _know_ what is broken both inside
Fedora Core and Extras so they can be fixed properly, and to know
what else is broken out in the wild, and give 3rd parties both
the knowledge that their software needs to be updated, as well
as a large enough amount of incentive to fix it during the
FC5 development timeframe.

The longer something is "broken" for somebody, I've found it acts
as a really good motivator to get things fixed properly in the
correct location.  The long term results (which is what I am
most interested in), is that people end up fixing /more/ things,
and fixing them /sooner/ when they have no choice if they want
to use the stuff.  Since this is a developmental time period,
that is perfectly acceptable.  Rawhide is and always has been
a roaming landmine of randomly breaking things that eventually
get fixed.

As people are discovering broken items, I'm keeping track of them
in bugzilla and other places, where I know we'll need to come
back and add some backward compatibility later on for the "final"
OS.  That will happen eventually, but with focus on the "later
on" part.

Short term pain for long term gain.

>>Illiteracy runs rampant, even at Red Hat!  ;o)  Fortunately,
>>it wasn't I who created this internal mailing list, so I get
>>to laugh and point fingers with the rest of you at whoever it
>>was.   ;oP
> 
> Maybe you could also inform your post/web master in order to fix this
> stupid mistake? Thanks.

It doesn't really bother me.  The world isn't a perfect place,
and I'm ok with that.  ;o)