Re: [4.0.1-0phase1v11] xlibgl1 shlibs
>> Branden Robinson <branden@debian.org> writes:
> What, specifically, do you suggest, again? Please show me the
> exact format so I don't screw it up. :)
libGL 1 libgl1
I'm still pondering this instead:
libGL 1 xlibgl1 | libgl1
but I'm not really sure that's a good idea... the intention being:
"it would be better if you have a hardware accelerated OpenGL
implementation, but this works even if you don't" (for example, Q3A
loads if you use only software rendering -- it just slow as molasses)
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].
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.
That is to say, an application linked with the libGL library in
xlibgl1 /must not/ fail to load if, say, mesag3 is installed instead.
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)
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.
> Also, I'm starting to think I need to pull libOSMesa into its own
> package, because the virtual package libgl1 can only be expected to
> provide libGL, not libGLU, libOSMesa, or anything else.
Yes, this is a valid point.
Thanks,
Marcelo
[1] If someone is wondering where I'm getting to here, NVidia's
implementation requires the architecture provided by the 4.0
servers, but does not use PI's DRI implementation. There's no
"dri" module and there's a glx module which I /guess/ does what a
"normal" dri module does. If some uncautious soul ITPs the
NVidia drivers (which, AFAIR, is not allowed by the license),
he'll have to Replace: xserver-xfree86 ... there's another vendor
working on self written drivers (I think it's 3Dlabs, but I'm not
sure atm) but from what I remember they are indeed using the DRI
infrastructure.
Reply to: