The NVIDIA packages and squeeze

Tue Sep 21 16:23:40 UTC 2010

On 2010-09-21 15:59, Julien Cristau wrote:
> On Thu, Sep 16, 2010 at 21:26:12 -0700, Russ Allbery wrote:
> 
>>     nvidia-graphics-drivers 195.36.31-3
> 
> Typo in debian/README.alternatives:
> +libgGL.so.1
> should be libGL.so.1

Oops. Fixed.

> It's a bit surprising to have the Xorg driver in a package with a glx
> name, but I guess that's due to both parts of the driver being in the
> same package previously..

Nearly everything was in nvidia-glx previously ... when splitting the
package I was considering moving the driver, too, but then things would
have become more complicated. But we still can do this post-squeeze -
suggestions for a package name welcome. Would
    xserver-xorg-video-nvidia and
    xserver-xorg-video-nvidia-legacy-ABCxx
be OK?

> Can you make the X driver package depend on xorg-video-abi-6.0?  I'm
> trying to get rid of the model we were using before so the X server
> doesn't have to conflict against old drivers, and the drivers depend on
> the server ABI they're built against (or work with, for the closed ones)
> instead.

No problem. Should we remove the Provides: xserver-xorg-video-6 at the
same time?

> I'm not sure why you conflict against the old 2.6.32-trunk header
> packages?

Because they sort badly (i.e. newer than 2.6.32-5) and we had at least
one bug report where the module was built for the wrong kernel because
-trunk- kernel/headers was still installed. We couldn't reproduce this
or track it down completely. There is no reason to have packages with
the bad abiname -trunk remaining installed, anyway.

> I don't understand how the libnvidia-compiler thing works, it installs a
> SONAME-less library in /usr/lib?  What uses it?

libnvidia-compiler.so is a huge plugin used by NVIDIA's CUDA/OpenCL
implementation. As it is not neccessary for all CUDA/OpenCL applications
(only if they are to be compiled on the fly) it is not bundled with
libcuda1.
Starting with 256.xx NVIDIA uses a soname matching the current upstream
version, so this will change with every new upstream. They will dlopen
libnvidia-compiler.so.NVIDIAVERSION then instead of
libnvidia-compiler.so as in 195.xx. Unfortunately there is no specific
search path being used, so this needs to go to /usr/lib. As the only
user is libcuda.so.1 with an exactly matching upstream version I decided
to go for a package without a soname to avoid going through NEW
everytime for no good reason. Versioned dependencies will ensure that no
mismatching upstream versions are installed. There is no use in having
different versions of libnvidia-compiler.so.* installed when there is
only one user (libcuda.so.1) available that will use exactly one of them.

> Maybe a stupid question: why do you need to install libGL.so pointing at
> the nvidia lib at all?

Hmm, for historical reasons. It has been shipped and messed around with
forever. I think, as long as we have the NVIDIA OpenGL headers available
(in /usr/include/nvidia/GL), we should ship a matching libGL.so. (For
the people that really want to to use NVIDIAs headers and link against
their library).

> The diversion+alternatives stuff makes my head hurt so I'm not sure I
> can review that.  Can you explain how this stuff works?

Historically, nvidia-glx (and the legacy and ia32 variants) have
diverted libGL.so, libGL.so.1 and libglx.so and created random symlinks
(I think that's the best description of the old maintainer scripts and
init script operations). Removing and purging often failed or did not
undo things correctly.

Now we have the lib*-nvidia-alternatives packages that handle
diversions, and setup alternatives via triggers
- they divert the library from MESA, so an alternative can be installed
in their place
- a trigger handles the adding/removing of the alternatives pointing to
the diverted libraries whenever libgl1-mesa-{glx,dev} get
installed/removed/modified (because we can't have a not existing file as
an alternative)
- the libgl1-nvidia-glx etc. packages install their "replacement" in a
location that causes no file conflicts and registers an alternative with
higher priority than mesa, they don't need to care about diverting stuff
- libgl1-nvidia-alternatives needs to handle both libGL.so.1 and
libGL.so because we need to avoid libGL.so from libgl1-mesa-dev pointing
to libGL.so.1 from NVIDIA (if libgl1-mesa-dev but not libgl1-nvidia-dev
is installed)

> libgl1-nvidia-dev.postinst doesn't install an alternative, but
> debian/libgl1-nvidia-dev.prerm removes it anyway, is that intentional?

Yes. We currently don't want to provide libGL.so from NVIDIA as an
alternative to the one from MESA. People should link with MESA at
compile time and run with NVIDIA.

> Was the '42' priority chosen at random (or, well semi-random, it's 42
> after all)?

I was considering using the NVIDIA major version, but currently we don't
support concurrent installation of current and legacy packages, so I
chose '42' higher than MESA ('5') and lower than NVIDIA (71, 96, 173,
195, 256)

> debian/libgl1-nvidia-glx.prerm removes the alternative from
> libgl1-nvidia-dev? (same with the ia32 versions)

That was superfluous, thanks. For the ia32 variant there is no separate
-dev package, so both libGL.so and libGL.so.1 have to be handled (even
if libGL.so is not registered as an alternative currently).

> I don't understand debian/libgl1-nvidia-glx.symbols.common.in,
> libGL.so.1 ABI is set in stone by http://www.opengl.org/registry/ABI/ so
> there shouldn't be any need for symbols for it.

There is no symbols file for libGL.so.1 being installed in the package,
only shlibs files pointing to MESA are being used.
The remaining symbols are for NVIDIA's "internal" libraries.

> I'm not sure diversion+alternative for
> /usr/lib/xorg/modules/extensions/libglx.so is the best plan as opposed
> to installing in a directory which the module loader will check first

Is there a possibility to "override" libglx.so from Xorg without
diverting it away?

> (there's no such choice for libGL.so.1 since the ABI spec says it's in
> /usr/lib).  Although I guess that makes it possible to switch
> implementations while keeping the package installed.

The possibility to switch was something users were asking for. This may
work now, but has not been tested in detail.

There are currently three providers (that I know) for libGL.so.1 and
libglx.so: NVIDIA (non-free), FGLRX (non-free), MESA/Xorg (free). (If
you count the NVIDIA legacy drivers separately, there are more
providers). If these packages agree on some way to handle their
co-existence via alternatives/diversions/triggers/conflicts/... in a
common way, maintaining the non-free variants will become easier in the
future. But that's a task for squeeze+1. The things I implemented now
for nvidia-graphics-drivers(-legacy-*) are an example how this could be
done - and a great improvement over the previous mess.

> nvidia-glx.NEWS can probably drop the advice to use 71xx by now.

Correct.

> Do the nvidia packages do anything to prevent nouveau.ko from being
> loaded?

nvidia-kernel-common (all binary module packages and the dkms packages
depend on this package) installs a blacklist entry in /etc/modprobe.d/

> I guess the CL stuff will conflict if/when mesa grows an OpenCL
> implementation? (Obviously not a concern for squeeze)

We will see how things work when new implementations arrive. But since
libopencl is only some wrapper library, it should be replaceable by a
free implementation like we could do for libvdpau1.

>>     nvidia-graphics-drivers-legacy-173xx 173.14.27-1
>>     nvidia-graphics-drivers-legacy-96xx 96.43.18-1

These two use the same base packaging as nvidia-graphics-drivers, so
most things you wrote here will apply there, too (and everything we fix
in n-g-d can be easily merged into the legacy packages).
They don't have the -alternatives packages (we use the ones from
nvidia-graphics-drivers to avoid code duplication) and all the new stuff
(vdpau, cuda, opencl, ...)

>>     nvidia-graphics-modules 195.36.31+1
>>
> Will look at those later, sorry for the delay.

Thanks for reviewing.

Andreas