Bug 101775
Summary: | Move files to XF86-Mesa-libGL from XF86 | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux Beta | Reporter: | Peter Backlund <peter.backlund> |
Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | beta1 | CC: | andreas.bierfert, gt, nobody+pnasrat, pmatilai |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-04-20 14:57:38 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Peter Backlund
2003-08-06 18:45:20 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. 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, etc. 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: /usr/X11R6/lib/modules/other/nvidia or /usr/X11R6/lib/modules/vendor/nvidia 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. 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? /Peter Sure, please file a new request for that. Make it filed against XFree86 for now though. 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. 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. |