[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.



 [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

Reply to: