Hope you don't mind if I CC my reply to the Debian X mailing list. On Thu, Sep 21, 2000 at 12:28:54AM -0700, Terence Ripperda wrote: > I'm from NVIDIA, working on our 2d/3d drivers. Now that there are XFree86 > 4.0.1 > packages in development, I'm looking at getting some .deb packages together > for > our drivers. I was looking at what you had so far for xfree86 and mesa/glx. I > had a couple of requests: > > libGLU - will you be providing the libGLU library as part of the xlibmesa > package, or seperately. It seems like it would be better for libGLU to be > seperate > from libGL, sort of like libglut is, since it's not really dependent on a > specific > version of libGL (or it shouldn't be).
It is my intention to defer to the SGI OpenGL Linux ABI standard. That
says that two shared libraries should be provided: libGL.so.1 and
libGLU.so.1; that XFree86 currently builds the former but not the latter is
an issue that they are working to rectify. Once they have done so, I will
be shipping libGLU in the "xlibmesa3" library (and its headers and static
vesion in "xlibmesa3-dev").
There is not yet official Debian policy on this matter, but I'm starting to
realize we need one. I think Debian should follow the existing standard as
drafted by SGI; any additional shared libraries not covered by that ABI should
be
shipped in separate Debian packages, so that all ABI-compliant
implementations can Provide: the virtual package "libgl1".
Brian Paul advised me to ship libOSMesa with xlibmesa, but in light of the
fact that some GL implementations might not have that, I'm going to deviate
just a little bit from his advice. I will be moving this library back out
into an "xlibosmesa" package.
> libglx.a & libGLcore.a - these files are in fact specific to the version of
> libGL used, but so far every package has them included with the base X
> modules.
> This is probably due to the modules being X modules and distributed with X,
> but
> functionally they are part of xlibmesa providing opengl functionality, and
> aren't
> very useful seperately. It would be a beautiful thing if you could move them
> into
> the xlibmesa package.
I'll have to check with what the ABI says, but Debian Policy says that
static libraries are shipped in "development" (i.e., "libfoo-dev")
packages.
> Our driver will install libglx.so and libGLcore.so, which don't conflict with
> the libglx.a and libGLcore.a files in the filesystem namespace, but do
> conflict
> in the X module namespace. When loading a "glx" module, X will pick up
> libglx.a
> before libglx.so. So far, with RPM binaries, we're forced to rename those
> libraries from another package. It would be much easier on everyone involved
> if we
> could just conflict/replace all other libgl1 providers, and not have to worry
> beyond
> about conflicts beyond that.
You can provide an absolute path to a module name as an argument to the
Load command in the Modules section of the XF86Config file. I think this
is preferable. There are underhanded things that your package could do to
get the XFree86 modules out of the way, but let's see if we can negotiate
something more friendly, first. :)
> The second thing (libglx.a/libGLcore.a) is infinitely more important than the
> first (libGLU), and it would be wonderful if we can work this out.
I think we can. Do you like the absolute path idea? E.g.:
Section "Module"
Load "/usr/X11R6/lib/modules/libglx.so"
EndSection
Heck, it might be an even better idea to put the module in a place specific
to the package, for instance:
Section "Module"
Load "/usr/lib/nvidia-driver/libglx.so"
EndSection
In fact, first analysis leads me to believe that reserving the XFree86
modules directory for modules shipped by XFree86 might be a good idea.
Completely eliminates the possibility of namespace collision in the
filesystem.
Let me know what you think (that goes for the folks on debian-x as well).
--
G. Branden Robinson | Never underestimate the power of human
Debian GNU/Linux | stupidity.
[EMAIL PROTECTED] | -- Robert Heinlein
http://deadbeast.net/~branden/ |
pgpwxgjgEoIci.pgp
Description: PGP signature
