On Sun, Nov 13, 2005 at 11:03:13AM +1100, Daniel Stone wrote: > libglx is an xorg module. It is originally provided by the XFree86 DDX. > Some drivers feel the need to provide an alternate version, and that's > great. But nvidia's is entirely specific to nvidia. xserver-xorg's > works with all the drivers in xserver-xorg.
> If xserver-xorg and nvidia-glx Replaces each other, as was the original > suggestion in this thread, No, the suggestion was: Please add the necessary conflicts or replaces or whatever happens to be appropriate in this case. I don't claim to know what the appropriate technical solution is. I am only asserting that the current behavior on the part of xserver-xorg is incorrect, per Debian policy and the RC bug policy for etch. > the behaviour is wildly non-deterministic, and you have no idea if you > will have a working setup or not. I posit that this is possibly > undesirable. In which case, I expect that the appropriate course of action is for xserver-xorg to Conflict: with versions of nvidia-glx which contain this file without diverting. I don't know what this means the correct fix should be for nvidia-glx; obviously, conflicting with xserver-xorg is not a sane option, so either the file should be moved or the package should divert the xserver-xorg version of the file. > The solution as I see it is pretty simple. Add a diversion on libglx.so > like there already is for libGLcore.a, and possibly adjust the GLcore > one if there's also a .so available. Add a Conflicts on older versions > of nvidia-glx from xserver-xorg. Which is still messy, but there you > go. Yes, that's a perfectly reasonable solution AFAICT. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
