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
[EMAIL PROTECTED] | than sheer incompetence!
http://www.debian.org/~branden/ | -- J. L. Rizzo II
PGP signature