Games doesent work in Fedora test 3

[nosp]

Wow, hope I'll be more polite in this response so I don't get anyone
upset.

On Fri, 2003-10-24 at 06:55, Mike A. Harris wrote:
> 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.

I completely understand what you are saying about what rpm's saying. 
However you're not disputing my point that apt's responses are valid and
not "broken," nor are you disputing my point that removing the Mesa rpm
causes rpm/yum/apt to complain about XFree-lib's requirements unless you
override some of their defaults with --nodeps.  In that case we agree
here and can move on.


> >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

Umm...yes, I agree and always have.  Substitute "a lib provided my Mesa"
for "Mesa" in my original sentence.  Thought my abbreviation was obvious
but sorry for the confusion.  I think we can finish with this point too.


> 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!

Your solution does not result in rpm/yum/apt thinking there is a
fully-satisfied package dependency graph for installed packages.  That's
part of what I envisioned "solving" the problem would entail.  If you
think that's not necessary then I would agree your approach is fine.  If
it is necessary, the root of the problem is that only the Mesa rpm
provides libGL and nvidia's "packages" are not rpms.  I suppose I was
expecting you to say "nvidia should fix their 'packages' to be RPMs." 
Since you've said that elsewhere and I agree with that...I think we've
closed this point.


> 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...

Ibid.  I won't bother repeating myself either. 

> >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>

Unless I'm mistaken there is no nvidia package; this together with your
later confirmation that you can't make an rpm "conflict with something
that is installed that is not an rpm" means that we have to get nvidia
to get their installer to make an rpm, or find another solution.

Here's why I think there is no nvidia package: 
# rpm -q --whatprovides /usr/lib/tls/libGL.so
file /usr/lib/tls/libGL.so is not owned by any package

# ls -l /usr/lib/tls/libGL.so
[...] /usr/lib/tls/libGL.so -> libGL.so.1

# ls -l /usr/lib/tls/libGL.so.1
[...] /usr/lib/tls/libGL.so.1 -> libGL.so.1.0.4496
(this is the nvidia driver)

To clarify, I am happy to ask nvidia if they would change their
installer to create rpms for rpm-based distros, or allow a third party
to distribute an rpm.  If you don't have any objections to that course
of action I will pursue it.

> 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

sounds great

> That will make life easier for users, for Nvidia, and for Red Hat 
> IMHO, which is the end goal.

Sounds great too.

>   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).

I am sure they are happy you did this, and so am I.


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

Agreed, it's unfortunate.


> >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).

This is all users of nvidia's installer, since it doesn't use rpms.


> >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.

Yeah, so we agree; it's "too fragile," aka an "ugly hack."


> 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.

Appreciated.