Bug 101775 - Move files to XF86-Mesa-libGL from XF86
Summary: Move files to XF86-Mesa-libGL from XF86
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: beta1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-08-06 18:45 UTC by Peter Backlund
Modified: 2007-04-18 16:56 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-20 14:57:38 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Peter Backlund 2003-08-06 18:45:20 UTC
Description of problem:
The files libglx.a and libGLcore.a in /usr/X11R6/lib/modules/extensions belong
to XFree86. It would be much better if they instead belonged to
XFree86-Mesa-libGL, because then it would be very easy to replace the entire
OpenGL library and associated files with other implementations (Nvidia for
example, possibly others too. ATI? Matrox?). 

Now, Nvidia's installer cruedly removes those files, and other, gentler
packaging efforts rely on moving files around in %pre and %postun...this could
easily be done with a Conflicts: XFree86-Mesa-libGL instead, if the packaging
was done as I suggest.

Version-Release number of selected component (if applicable):

Comment 1 Paul Nasrat 2003-08-07 06:07:22 UTC
Just so people know this is already in the src.rpm change the first enable_sdk
variable as so:

%define enable_sdk 1

There is some tweaking to be done, I removed the via driver from host.def and
ran imake/make manually.  I think makedepend is broken on the tree (as it is
with the patched XFree86 produced from rpmbuild -bp XFree86.spec), maybe the
mkmf should be patched to perform like the FAST=1 setup for the XFree86 tree.

Comment 2 Mike A. Harris 2003-08-12 08:57:02 UTC
I've thought about this very carefully for a while before commenting, to
ensure that enough thought was put into it before a decision was made.

I've decided that I disagree with this change for various reasons.  The main
reason is that splitting things up more doesn't really make life on the end
user much simpler, in fact, quite the opposite is true.  It would introduce
a number of other complications into the mix as well, and require users to
jump through a lot more hoops to try to install updates, or 3rd party drivers,

There really is no good reason for any of the X server modules we supply to
be split into separate packages, with the possible exception of video drivers
themselves, but that is another story to be addressed in the future hopefully.

The true proper way to solve this problem, which both keeps things "simple",
which is very important, and also allows Nvidia and other 3rd party driver
vendors who might supply X server modules other than just their video
drivers, is for those vendors to install their modules into a separate
directory structure that is NOT part of the default installation and does NOT
conflict with existing files supplied by the OS vendor (us in this case).

What Nvidia and other 3rd party vendors *should* be doing, is installing
their modules into some other directory such as:


And their configuration tool should then prefix the ModulePath directive
in XF86Config with the path to their modules.  This would result in the X
server looking for their modules *first*, and falling back to the XFree86
supplied Red Hat shipped ones only if vendor supplied modules did not exist.

The additional benefit of this solution, is that Nvidia or other vendor's
RPM packages could install without overwriting or damaging the Red Hat
supplied XFree86 installation (and creating a nightmare of technical support
problems both for Nvidia, Red Hat, XFree86.org, and others in the process).
Also, users could more easily toggle using the supplied "nv" driver simply
by commenting out the special Nvidia module path in the config file without
fussing around.

This allows packaging to remain simple, and in fact become even simpler,
as we would probably be able to get rid of the XFree86-Mesa-libGL and
XFree86-Mesa-libGLU subpackages entirely, as they would no longer conflict
with vendor supplied drivers/modules.

For this to be most beneficial however, it should not really be a Red Hat
specific thing, but an OS and distribution neutral standard, one agreed upon
by various OS vendors and distributions, as well as XFree86.org and hardware
vendors as well if possible.

This is something worthy of discussion on the XFree86 devel mailing list, and
so I am going to leave this bug report open just as a reminder that this
problem needs solving sooner rather than later.  Nonetheless, for the time
being, Nvidia and other vendors can certainly implement the solution I
describe above even as a nonstandard method, since XFree86 as supplied, does
in fact support the ModulePath directive, and I don't consider it an abuse
of XFree86 configuration if a vendor requires it's usage.

I'll also talk with Nvidia, ATI, and other vendors and solicit feedback, and
with Debian, FreeBSD and other distribution X packagers.

Thanks for the report.

Comment 3 Peter Backlund 2003-08-15 14:19:58 UTC
Sounds cool. Now, something that would be very nice to have in rpm scripts is
the ability to modify ModulePath via redhat-config-xfree86 (from cmd-line that
is). Otherwise, each packager will end up with his own perl/sed hack, which will
inevitably cause problems. Alternatively, support could go into an X utility
like xset or something. 

Should I post this in BZ separately, as a feature request? 


Comment 4 Mike A. Harris 2003-08-15 20:47:17 UTC
Sure, please file a new request for that.  Make it filed against XFree86 for
now though.

Comment 5 Mike A. Harris 2004-07-05 22:32:54 UTC
livna.org has nvidia driver rpm packages available which if I
understand correctly, install the nvidia files to alternate
locations and configure everything to just work.

We do not have a general framework for this for 3rd party drivers
yet at this point, however it is still considered for sometime
in the future, probably within the Fedora Core 4 or 5 timeframe.

Deferring for future development.

Comment 6 Mike A. Harris 2005-04-20 14:57:38 UTC
Most people are using Livna.org's ATI and Nvidia packages nowadays, which
"just work" more or less, and so this one has more or less become
irrelevant for the most part.

We'll be investigating various improvements to driver installation and
configuration, etc. in future OS releases as well, so these types of
issues will gradually get better over time.

No plans of splitting out the files originally requested into separate
rpms however, as it really isn't necessary, so going to close WONTFIX
for now.

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