The NVIDIA packages and squeeze

[Julien Cristau]

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

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..

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.

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

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

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

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

libgl1-nvidia-dev.postinst doesn't install an alternative, but
debian/libgl1-nvidia-dev.prerm removes it anyway, is that intentional?
Was the '42' priority chosen at random (or, well semi-random, it's 42
after all)?

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

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.

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
(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.

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

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

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

>     nvidia-graphics-drivers-legacy-173xx 173.14.27-1
>     nvidia-graphics-drivers-legacy-96xx 96.43.18-1
>     nvidia-graphics-modules 195.36.31+1
> 
Will look at those later, sorry for the delay.

Cheers,
Julien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20100921/41ecb3d2/attachment.pgp>