On Mon, Aug 14, 2000 at 01:57:49AM +0200, Marcelo E. Magallon wrote: > That's not really a problem (please bear with me for a second here, > I'm trying to put some order in my thoughts)... the real problem is > the libGL provided by xlibgl1 *requires* a GLX implementation on the > server. This is provided by libglx.a (xserver-xfree86), which is, in > fact, the only one currently available that would work with the > library in xlibgl1. Supposing some vendor goes ahead and writes his > own DRI-using drivers for Linux, they should provide a "driver" > module and a "dri" module. They would still be using the GLX > implementation in xserver-xfree86 and the libGL in xlibgl1 [1]. I don't really see how this is any different from the current situation with X protocol extensions. Of course, extensions have to be supported on both the client (library) side and on the server side. While a package can declare a dependency on a library, it can't declare one on a server extension, because the X server may not even be running on the same computer. > OTOH, it's perfectly possible to replace the libGL provided by > xlibgl1 without having to replace the GLX provided by > xserver-xfree86. Such a replacement could be SGI's Sample > Implementation -- which would be a nice thing to have in Debian, IIF > the license passes thru -legal. Sure. I thought this was the whole point behind the libgl1 virtual package. > That is to say, an application linked with the libGL library in > xlibgl1 /must not/ fail to load if, say, mesag3 is installed instead. As I understand it, packages should be depending on libgl1. If any packaging providing libgl1 fails to have some symbols defined, that is a bug in the package claiming to provide libgl1. > OTOH, if a GLX-providing X server is not present, the application > will load, but fail immediately with a message similar to 'GLX > extesion not present in X server' (just tried with a 3.3.6 server). > To me, having a Dependency of xlibgl1 on xserver-xfree86 sounds > artificial (not to mention, wrong -- for the same reason xlib6g > doesn't depend on xserver) Yes, because the X server may be running on a different machine from the client. We can't use package dependencies to solve this problem. > And finally, there's no libgl1 virtual package. Branden, have you > asked about this on -policy? Up until now, it was being used > 'internally' by the mesa packages. It's been agreed on by consensus between myself and the mesa maintainer. At some point someone will need to draft a policy proposal about it, but it's not high on my priority list. -- G. Branden Robinson | I am sorry, but what you have mistaken Debian GNU/Linux | for malicious intent is nothing more branden@debian.org | than sheer incompetence! http://www.debian.org/~branden/ | -- J. L. Rizzo II
Attachment:
pgpXsysfiLls5.pgp
Description: PGP signature