On Sat, Nov 12, 2005 at 11:21:32PM +0000, Stephen Gran wrote: > Right, I was talking about having xserver-xorg do it as well. Let me > rephrase a bit: > > I believe the nvidia packages in debian are doing it right now because > they had to be coinstallable with xserver-xfree86. Since xorg is the > new kid on the block, so to speak, it can no longer claim "I owned the > file first", so it is an xorg bug at least partly. /me frowns. xserver-xorg is a logical continuation of xserver-xfree86, and I daresay the userbase of xserver-xorg without proprietary drivers is much greater than that of xserver-xorg with proprietary drivers. Also, the FHS has something to say about /usr/X11R6. If you want to assert that modules under /usr/X11R6/lib/modules belong to nvidia, and that xorg is squatting on them, you're welcome to, but I will argue the point strenuously. Especially when noting that the modular tree (X11R7, which is code-equivalent to X11R6.9) uses /usr/lib/xorg/modules as its equivalent to /usr/X11R6/lib/modules. 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, 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. xserver-xorg could simply stop installing libglx.so, which would remove all GL support (direct and indirect) from X apps, except when you use the nvidia driver. I posit that this is also undesirable. Alternately, the nvidia driver could just divert libglx.so like it already diverts libGLcore.a (for, I might add, *exactly* *the* *same* *reason*), and everyone could move on with their lives. Look, it's a non-free package, and it's a driver for xserver-xorg. It's not like xserver-xorg is a subset of nvidia, it's the other way around. So bending over backwards for it seems a bit odd. Particularly as other drivers may choose to divert anything else under the sun, depending on what they want to do, and what should you do then? 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. > Additionally, all these proprietary add on drivers that insist on > providing their own gl libraries usually don't bother with dpkg-divert > calls (presumably because they are packaged by monkeys at ATI or > something), so having some of that logic in the xorg packages would be > helpful in the general case, even if there was no bug in xorg as such. Look, I'm no fan of proprietary drivers, but calling the driver people 'monkeys' is a bit harsh. Especially when they provide RPMs that people insist on alien'ing for their older drivers, and they now provide an installer that generates debs, and ... wait for it ... does the right thing with diversions. Which leaves nvidia. And you can call them monkeys for their packages not working with Debian by default, but only as much as you can call Debian monkeys for not working with nvidia stuff by default.
Attachment:
signature.asc
Description: Digital signature