On Tue, 28 Oct 2003, Elton Woo wrote:
> This is because the Nvidia ugly hack to delete libGL only gets
> part of it. The i686 TLS libGL is left, and if your system
> autodetects as being i686 compatible and compatible with TLS,
> that library will override anything installed in the general
> location (where Nvidia puts theirs). As such, you end up using
> Mesa software libGL, and it tells you no DRI driver is available,
> which is correct.
Newbie (and perhaps stupid) question: is there a way to remove the
nVidia GL, so that one can keep the Mesa ones? ... Or am I obliged to
continually remove the latter? As it stands, there two steps necessary
whenever I get rawhide updates:
That depends on wether or not the Nvidia stuff was installed with
rpm or not. If it was, then uninstall the Nvidia rpms. If it
wasn't, then perhaps they have an uninstall script to run. If
not, go one directory at a time through your hard disk looking
for files Nvidia installed outside of RPM's scope, and delete
them by hand with rm. By definition, package managment involves
using packages and package management software - rpm.
1) re-run the nVidia installer whenever the kernel is updated
2) remove using --nodeps whenever XFree is updated (since I can't
update without including the Mesa-libGL package...
... or am I asking the impossible / unreasonable?
No, but you're asking the wrong people. Unless Nvidia's drivers
are installed via rpm, and their rpm package provides libGL
properly, then anything depending on libGL will have dependancy
problems. That's something that needs fixing in Nvidia's rpm
packages. Only I'm being told they don't have rpm packages
anymore, so it's more difficult.
We are not going to make ugly hacks for software installed
outside of rpm context. It defeats the entire purpose of rpm in
the first place, and opens the door for 10000 other software
companies out there to request and expect special treatment and
hacks for their software too.
I'm happy to develop useful and generic solutions that do use rpm
packaging in order to solve problems for 3rd parties however, and
that is why XFree86-Mesa-libGL is a separate package to begin
with.
--
Mike A. Harris
ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat