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

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).


Reply to: