Games doesent work in Fedora test 3

[Mike A. Harris]

On Thu, 23 Oct 2003, nosp wrote:

>> That just shows you're using a method that is inherently 
>> flawed/broken to try to uninstall the package.  I don't recommend 
>> using apt for anything ever.  Use yum, or use rpm directly.
> 
>Hmm -- I'm not sure that apt is telling me anything that rpm doesn't
>tell me; actually apt shows me, quicker, how big an effect my desire to
>remove Mesa will have.  Here's what rpm tells me:

apt is telling you it'll gladly uninstall half your system if you 
like to remove Mesa.  RPM would tell you that there is 
dependancies on Mesa from other applications, then you'd say to 
yourself "yes, but I am uninstalling one libGL.so.1 and 
installing an alternative libGL.so.1, so when I'm done all 
dependancies will still be met", then you'd use --nodeps to 
uninstall Mesa, and then install Nvidia, and everything is happy.

 
>        libGL.so.1 is needed by (installed) xscreensaver-4.13-1
>        libGL.so.1 is needed by (installed) xmms-1.2.8-2.p
>        libGL.so.1 is needed by (installed) XFree86-libs-4.3.0-40
>        libGL.so.1 is needed by (installed) XFree86-tools-4.3.0-40
>---
>
>Clearly the dependency of XFree86-{libs,tools} on Mesa is the
>"problem."  I disagree that apt is flawed/broken.  But is there a
>solution to this?  Probably more relevant in response to your next
>point...see below.

Wrong.  There is absolutely *NO* dependancy on Mesa.  The 
dependancy is explicitly on libGL.so.1 as you quote above.  
*ANYTHING* that provides a library called libGL.so.1 by 
definition solves the dependancy, including Nvidia's libGL.so.1

I already gave you the solution, uninstall Mesa-libGL using rpm
with --nodeps, and immediately install the Nvidia packages.

Problem solved.  Works for hundreds of users, and can work for 
you too!

>> Normally the --nodeps would be strongly advised against for any 
>> other command.  In this case the idea is "We know we're 
>> uninstalling this package intentionally because we are installing 
>> an alternative package which provides the same functionality to 
>> the applications that require this one".
>
>Yes but then apt (and, I presume, yum) will tell me I have a
>broken package set installed (some packages are installed that
>depend on a package I don't have installed).  I can fix this by
>telling apt (prob. yum too) to pretend it has the missing Mesa
>rpm.  I would probably have to do the same trick to make rpm
>itself happy.  It's just inconvenient to tell all the packaging
>apps (rpm, apt, yum) individually that "yeah we really have Mesa
>even though it's not installed."

I gave you the solution that works properly.  I'm not going to 
bother repeating myself 500 times however or explain in detail 
how rpm or apt works.  You can use my solution, and have it work 
for you too, or you can think too much about it, and worry about 
it and keep a non-working system.  Your choice...

>I don't think any of this helps us with the original question,
>which was "how will Mike make the Mesa rpm explicitly conflict
>with the nvidia drivers."

Simple:

Conflicts: <Name of Nvidia package containing libGL.so.1>

That way Nvidia does not need to delete the files to avoid the 
conflict (which is wrong on so many levels it isn't funny), and 
users are alerted by RPM directly that the two packages conflict 
with libGL.  The proper solution to this is the one I've outlined 
above.  Nvidia's future rpm packages and installer can then stop 
deleting our rpm installed files and instead automate the process 
of doing:

rpm -e --nodeps XFree86-Mesa-libGL
rpm -Uvh Nvidia-package-name-containing-libGL

That will make life easier for users, for Nvidia, and for Red Hat 
IMHO, which is the end goal.  Remember, in previous releases 
there was no Mesa-libGL or Mesa-libGLU subpackages.  I created 
those 2 packages explicitly for one purpose - to allow 3rd party 
vendors to be able to easily replace either one or both of those 
libraries with their own custom libGL/libGLU (some vendors have 
their own libGLU for whatever strange reasons).

To date, I'm not aware of any vendors who have taken advantage of 
this unfortunately.  ;o(

>I just want to clarify that I think this effort to help smooth
>out this issue is very much appreciated by myself and, I
>imagine, other binary nvidia users.  So thanks -- my musings
>were merely a desire to get more insight into how you would
>tackle this problem.  The solution doesn't seem obvious to me
>because you have to make an rpm conflict with something that
>isn't installed by (an) rpm.  How would you do that?

You cant make an rpm conflict with something that is installed 
that is not an rpm.  I can make an rpm conflict with another rpm, 
which means people who install Nvidia's drivers with rpm would 
end up hopefully having a properly working system assuming Nvidia 
updates their rpms and driver installation procedure.  Users who 
install Nvidia's stuff without rpm are more or less on their own, 
and always will be, because rpm doesn't know anything about 
anything that isn't installed via rpm (and shouldn't).

>Could you make the rpm conflict with a file that only the nvidia
>installer created?  That would probably be too fragile a method,
>right?

Wether it would be technically possible via some ugly hack or not 
doesn't matter.  I wouldn't implement an ugly hack like that for 
any reason anyway.  People should use rpms, and if they don't 
then like has always been the case in the past for all software 
installation - they're on their own to solve whatever package 
conflicts or problems arise.

I want to make the situation better, but 3rd party vendors 
packaging stuff in rpms need to want to have things better too, I 
can only make things nicer on my side, but I can't make their 
side better.  I can help them to do so though if they're 
interested.


-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat