Stefan Dirsch wrote:

On Sat, Jun 23, 2001 at 11:41:11AM +0200, Ralf Corsepius wrote:

...

...

...

They lack the SuSE-7.2 specifics. Instead, I hacked that nvidia_glx.spec :)

1) For SuSE-7.2, SuSE has repackaged the original NVIDIA_GLX package, is installing to different locations than NVidia, added their switch2_nvglx script and changed several details => SuSE's NVIDIA_GLX is incompatible the NVIDIA's generic NVIDIA_GLX ;)

...

An actual problem however exists in with libGLcore, as compiling GL-apps with NVidia's GLX will add a linker dependency to libGLcore, which does not exist if using MesaGL[X]. Your approach does not help wrt. this.

We compile all of our OpenGL programs with MesaGL. I know :)

And they work with the nvidia driver. AFAIK libGLcore.so is loaded dynamically with dlopen(). Other- wise nVidia would have a big problem to convince the world to use for compiling their libGL. Hmm, ln -s libGL.so.xxx libGL.so?

I need to check the details, but I recall having seen rpm putting libGLcore into it's dependency list if building GL-applications with NVidia's drivers and if not having MesaGL installed at all.

...

The only benefit of using switch2*-scripts, I see, is potentially being able to switch between MesaGL[X] and NVidia-GL[X] at run-time (I think rpm-dependencies prevent this, however I haven't checked for this).

It is possible at run-time. That's the benefit of it. Just execute switch2mesasoft, then you'll have Software Rendering.

...

...

...

2) With SuSE-7.2, SuSE now provides a dummy NVIDIA_GLX package whose version number does not match with the actual NVIDIA_GLX (the dummy's version is greater than NVidia's) => Many beginners will not notice that they do not run NVidia's drivers.

We use this dummy package, because we can't provide the official NVIDIA_GLX RPM (license issues) and want to provide an easy update without having to change anything in the configuration for 3D. That the dummy's version is higher than Nvidia's is an error on SuSE 7.2 (will be 0.8 on SuSE 7.3). The user gets a warning during installation that these are dummy packages and he has to update with YOU (YaST Online update) the packages NVIDIA_GLX + NVIDIA_kernel, if he wants real 3D. root gets an email with the same content. And if you execute '3Ddiag' you will get the waring that you only had installed the dummy packages with the notice to update them with YOU. I know (I saw this warning), but referring to YOU is another dark chapter.

For some strange reason, I haven't been able YOU working since it exists. Probably because of me being behind a very restrictive firewall/proxy.

We are working on a solution for this. So it will be possible to specify a proxy with the next SuSE release.

I'd be lucky, if this was the only bug in YOU ;) 1. YOU does not save the options given in its "Expert-Dialog". Due to not being able to access the official sites, I am using a local mirror and therefore have to change the setting. Having to re-type these each time new is rather annoying. 2. YOU does not recognize rpms which have been previously been installed with rpm or YaST1. Result: YOU will unnecessarily install packages a second time. AFAIK, the actual cause is YaST2 using its own database instead of applying rpm. Sorry for having to say this, but I consider this to be severe basic design fault. 3. Error handling.

...

...

...

3) Wrt. to the NVIDIA_kernel modules, NVidia's site provides UP-rpms, but does not provide modules for the SuSE-kernel variants coming on CD.

You can find on nVidia's website NVIDIA_kernel RPMs for SuSE 7.0/7.1/7.2 containing NVdriver kernel modules for all preinstalled SuSE kernels. Where? I can only see UP-NVIDIA_kernel-RPMS ons http://www.nvidia.com.

http://www.nvidia.com/view.asp?PAGE=linux

Look for SuSE 7.2 ...

I would, but neither this URL nor ftp1.detonator do respond, currently.

...

I know ftp1.detonator.nvidia.com had had them for other SuSE versions, but somehow I don't seem to be able to reach this site anymore.

Sometimes the ftp server is down, sometimes nvidia deletes the complete directory with the drivers, sometimes nvidia renames all files in this directory. I can't do more than send them emails, if something changed again. I'm downloading our RPMs hourly via cronjob and get an email if this fails. I can't do more about this.

...

Wrt. "all preinstalled kernels": SuSE-7.2 provides a precompiled 2.4.4-4GB-SMP kernel, but your nvidia_glx.spec does not support it. => AFAIS, you do not provide precompiled modules for all precompiled kernels!

2.4.4-4GB-SMP is missing, but there are instructions to compile them yourselves in /usr/src/kernel-modules/nv_glx/README. BTW, Pentium SMP is not very common. Now, you've got me :) Why the hack am I using a Pentium kernel? My system is a dual PII :)

rpm -qpl NVIDIA_kernel-1.0-1251.suse72.i386.rpm /lib/modules/2.2.19-SMP/video/NVdriver /lib/modules/2.2.19/video/NVdriver /lib/modules/2.4.4-4GB/video/NVdriver /lib/modules/2.4.4-64GB-SMP/video/NVdriver

...

...

These RPMs also include the 'sources' with installation instructions, if you have self-compiled your kernel. NVidia's SRPMS do not contain your scripts and also do not consider your symlinks and /usr/lib/GL subdirectory.

I'm speaking for NVIDIA_kernel for SuSE --> see above. Doh, I am working too much and better should spend some time off. I did expect to see different RPMs for the different variants of kernels. I didn't expect a single rpm for all kernels.

...

...

...

I don't understand why SuSE doesn't simply put a nosrc.rpm on their site and tells people to d/l the tarball.

I don't understand, what you want to tell me with this sentence ...

Write an ordinary rpm.spec like you would do if you could distribute the sources, but then add NoSource-Rpm-Tags to your rpm.specs: .. Source0: ftp://ftp.nvidia.com/<actual-path>/NVIDIA_kernel-1.0-1251.tar.gz NoSource: 0 ..

rpm -bs nvidia_glx.spec then will generate a <package>.nosrc.rpm which would not contain the copyrighted sources, i.e. you could put this *.nosrc.rpm on your ftp-site without legal concerns.

Then tell people to download the tarball from NVidia and to run: rpm --rebuild nvidia_glx.spec

This would be an option. But you still need a compiler and kernel sources installed, the kernel sources must be configured and so on. So it's still not an easy task for a beginner. Well, most of the issues you list above, also are valid for your src.rpm, therefore using an src.rpm or nosrc.rpm would not make much difference from a user's point of view.

But there is one major advantage: Such a nosrc.rpm would enable users to rebuild the drivers without having to install all variants of kernel-sources and without having their kernel's config trashed when rebuilding the drivers. This primarily pays off and avoids problems if using non-SuSE-kernels or if using customized kernels. To some extend, using the rpm-tag BuildPreReq: can help resolving the rpm-dependencies, e.g. using something similar to this in your rpm.spec: BuildPreReq: gcc binutils kernel-sources

Best regards, Stefan Dirsch

Thanks, I wish SuSE had more employees who actively try to help finding problem solutions. Ralf