On Tue, Sep 21, 2010 at 18:23:40 +0200, Andreas Beckmann wrote: > On 2010-09-21 15:59, Julien Cristau wrote: > > 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? > I don't know, it might not be worth it. Let's discuss this after squeeze? > > 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? > You can keep it for now. When we move to video ABI 8 (or up, if we go to xserver 1.10 directly) then we'll drop those. > > 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. > OK. I guess it does no harm. > > 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. > ok. > > 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). > I don't know if these people exist, but ok :) Not worth revisiting for squeeze anyway. > > 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 [...] Thanks, that's starting to make sense. > > 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'll have to look at this again, then, because I haven't found how you avoid installing that symbols file with libGL.so.1 stuff. > > 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? > the dlloader has a list of directories to look at: /* Standard set of module subdirectories to search, in order of preference */ static const char *stdSubdirs[] = { "", "input/", "drivers/", "multimedia/", "extensions/", "internal/", NULL }; Probably not something to change for squeeze either anyway. > > (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. > ok. > > 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/ > That kind of sucks because it means that package has to be purged before nouveau can work again. Oh well. Cheers, Julien
Attachment:
signature.asc
Description: Digital signature