Bug 192141 - should glx libraries be put in their own package?
should glx libraries be put in their own package?
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-17 16:47 EDT by Lars Damerow
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-19 08:58:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
A patch to the xorg-x11-server.spec file to split the GLX libraries into their own package. (2.57 KB, patch)
2006-05-17 16:47 EDT, Lars Damerow
no flags Details | Diff

  None (edit)
Description Lars Damerow 2006-05-17 16:47:17 EDT
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
Comment 1 Lars Damerow 2006-05-17 16:47:17 EDT
Created attachment 129364 [details]
A patch to the xorg-x11-server.spec file to split the GLX libraries into their own package.
Comment 2 Mike A. Harris 2006-05-19 08:58:15 EDT
> 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.
Comment 3 Lars Damerow 2006-05-19 10:15:03 EDT
Hello Mike!

That makes perfect sense, and is much cleaner than what I've been doing. I'll
change my package.

Many thanks!
-lars

Note You need to log in before you can comment on or make changes to this bug.