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. branden@deadbeast.net | -- Robert Heinlein http://deadbeast.net/~branden/ |
Attachment:
pgpXfGsOz7qsa.pgp
Description: PGP signature