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
Attachment:
signature.asc
Description: Digital signature