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
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.
Version-Release number of selected component (if applicable):
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
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,
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
Hope this helps.
That makes perfect sense, and is much cleaner than what I've been doing. I'll
change my package.