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)
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
