Description of problem: Having libglx.so and libGLcore.so as a part of the xorg-x11-server-Xorg RPM makes packaging alternate GLX implementations difficult. It'd be much easier on those of us that need to do this if these two libraries were in their own package. I'm attaching a patch to the spec file that I use to recompile Xorg whenever I need to make a new release. This patch allows me to make an alternate package with a GLX implementation work with Xorg simply by having "Provides: GLX" in its spec file. Without something like this patch, my alternate GLX package has to have some nasty post and trigger scripts in order to do the right thing. Thanks! -lars Version-Release number of selected component (if applicable): 1.0.1-9.fc5.1.1
Created attachment 129364 [details] A patch to the xorg-x11-server.spec file to split the GLX libraries into their own package.
> should glx libraries be put in their own package? Any 3rd party replacement modules should be packaged in a separate directory somewhere on the system (there is no standard location defined), and the ModulePath directive should be used in the X server config file to override the compiled in ModulePath. As long as the standard path is the last specified one in the X server config, the server will search for modules first in the vendor specific custom override director(y|ies), and then fall back to the standard distribution provided directory. 3rd party vendors should not ever put X server modules into the system provided default X server module directory, and should not move, rename, or delete any modules from the system supplied module directories for any purpose. There are 3rd party driver rpm packages available which utilize this method to install drivers, libglx and other modules into an alternative location and reconfigure the X server to find them in the new place. As an example, both the nvidia and ati-fglrx video drivers have been packaged by livna.org to install in a location that does not conflict or harm OS provided X server modules, while overriding libglx module, libGL, etc. This is the solution we recommend to all 3rd party rpm packagers, open source and proprietary to ensure maximal compatibility and to keep conflicts and other trouble to a minimum. Our X server modules (not including drivers) are packaged in one package along with the X server intentionally. Hope this helps.
Hello Mike! That makes perfect sense, and is much cleaner than what I've been doing. I'll change my package. Many thanks! -lars