Re: READ THIS; Debian XFree86 4.0.1 mini-FAQ
>> Joshua Shagam <joshagam@cs.nmsu.edu> writes:
> I see no reason that libGLU *as it stands now* needs to be bundled
> with any specific OpenGL implementation or driver.
It's just what the Linux OGL base decided. Playing along is the most
sensible thing to do as incompatibilities between different OGL
implementations has been one of the largest sources of headaches in
the past (glXCreatePixmapMESA anyone?)
> (Myself, I only use one libGLU call in my entire 3D engine, and
> even that could be easily replaced with a raw OpenGL call if I
> weren't so lazy.)
That very one call is probably the reason some large ammount of
programs link against libGLU. I guess a rather small ammout of those
programs use the mipmap functions, and a even smaller use the
tessellation or nurbs functions.
> Basically, I think there should just be one libGLU which is
> packaged on its own (for now), and any program which uses GLU
> should just have it as a requirement.
The OGL base specifies you should provide both. It is true that you
can mix and match any libGL (xlibmesa3, NVIDIA's, ...) with any
libGLU, but IMO it's cleaner if the vendor provides both. Saying
it's ok to do otherwise leads you a step closer to the current
situation with the NVIDIA drivers, where you don't get a proper
development environment from them.
You could argue that it could be possible to split libGLU into it's
own package. Technically there's nothing wrong with that, except
that every package providing libgl would have to have a 'Depends:
libglu' introduced (since the one package providing libgl had libGLU
in it) and this gratutiously breaks the possibility of installing
woody compiled packages on a potato system (because of other factors
this probably has already happened, but introducing yet another one
is not nice).
Marcelo
Reply to: