Compiling NVIDIA driver for -ntpl kernel

Mike A. Harris mharris at redhat.com
Tue Oct 28 20:49:42 UTC 2003


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





More information about the test mailing list