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

Re: [4.0.1-0phase1v11] xlibgl1 shlibs

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

>  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

>  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: pgpbZCaeCA4k0.pgp
Description: PGP signature

Reply to: