Description of problem: Package xorg-x11-0.6.6-0.2004_03_30.5 for i386 requires Glide3 >= 20010520 but the x86_64 version of the same package does not. However, Glide3 is built for the x86_64 platform.
The Glide3 package contains "ExclusiveArch: %{ix86} alpha" and has done so for quite a long time now. I just checked our buildsystem, and there is no record of any x86_64 Glide3 packages having ever been compiled. Here is the current head of the tree: pts/57 mharris@porkchop:/mnt/redhat/beehive/comps/dist/fc2/Glide3/20010520-30$ dir total 20 drwxrwsr-x 5 buildsys buildsys 4096 Mar 31 12:01 ./ drwxrwsr-x 3 buildsys buildsys 4096 Mar 31 12:01 ../ drwxrwsr-x 2 buildsys buildsys 4096 Mar 31 12:01 SRPMS/ drwxrwsr-x 2 buildsys buildsys 4096 Mar 31 12:01 i386/ drwxrwsr-x 4 buildsys buildsys 4096 Mar 31 12:01 tests/ pts/57 mharris@porkchop:/mnt/redhat/beehive/comps/dist/fc2/Glide3/20010520-30$ My guess, is that you have the 32bit Glide3 for x86 installed on your AMD64 system. That most likely will not work under a 64bit kernel though, as 32<->64bit thunking is not available for DRI currently, and we don't support Glide3 on AMD64 anyway. Just for fun though, if you're interested in testing it out, comment out the Exclusivearch line in the Glide3 spec file and recompile it on AMD64 as 64bit, and give it a whirl on the tdfx driver to see if it even works or not. We've never built it nor tried it on AMD64, so I'm unsure if it will work or not, but it'd be interesting to find out at least. ;o) I think the X server might hard code the path to Glide to dlopen() the module. As an aside note, the BuildRequires on Glide3-devel is no longer needed, due to dlopen() being used now, so I'll probably kill the Glide3-devel subpackage sometime down the road too. Closing as 'NOTABUG' for now, but if you try rebuilding Glide3 as per above, I'm interested in hearing your results via email preferably. Thanks Gene, TTYL
Mike, I am going to open this again but change it to distribution and x86_64. The packages are i386 but are part of the x86_64 set and you indicate that they should not work.
I think the issue is, they will not work, but they are a requirement of a requirement, etc... Openoffice.org is what requires the xorg 32bit pieces. xorg is what requires the glide. So we end up with one useless package to allow for a somewhat usefull package to allow for a usefull package :)
Fixed in comps, they should no longer end up in the tree.
Justin) The master 'xorg-x11' package has a hard coded "Requires: Glide3" to ensure that if the 32bit X server package is installed, that the 32bit Glide3 package is also installed for x86 installations. IMHO, the 32bit "xorg-x11" package should not ship on AMD64 at all, as we do not want a 32bit X server installed on a 64bit OS. The 64bit package should be installed. If the 64bit "xorg-x11" package is installed, it should not "Requires: Glide3", as it is ifarched. Does this make sense?
The 32-bit xorg-x11 package does not, to the best of my knowledge, ship on x86-64. Where it was getting pulled in was via Glide3-devel in the development libs section of comps.
That might explain it. Open Office requires xorg-x11-libs, but I do not think that xorg-x11-libs requires xorg-x11 proper. Mike) From what you said completely makes sense, except that we have hit a limitation of rpm it seems. In the case where 32bit requires include things which will not run on 64bit systems, requires cannot be ifinstallarched (ie ifarch i386 installed on %{ix86} require foo, bar ifarch i386 installed on x86_64, PPC64 require bar) The only option in such a scenario is to break out the required libs into a seperate RPM.
That is strange. I updated all of the xorg-x11-* packages (both x86_64 and i386) on my x86_64 system with up2date and there was no complaining about Glide3 being missing ... I also upgraded all the openoffice.org packages ... updated to development/rawhide current as of today (13 Apr). The first time I ran across Glide3 is when I went to do the same upgrading on a dual processor P-III. I believe that Glide3 can be removed.