Java Mailing List Archive

http://www.redhatconfig.com/

Home » Mandriva Cooker »

Re: [Cooker] Cooker update knocked out nvidia driver and nvidias
opengl driver

Steve Morris

2008-06-10

Replies: Find Java Web Hosting

Author LoginPost Reply
Colin Guthrie wrote:
> Steve Morris wrote:
>> Colin Guthrie wrote:
>>> Steve Morris wrote:
>>>> Ok, I'll let things rest, I could continue on ad infinitum here, I
>>>> guess I will just have to accept that Mandriva/Linux does things in
>>>> a way that just makes no logical sense to me.
>>>
>>> Did you see my reply dated 15:47? I tried to explain things as
>>> clearly as possible. I think you should be able to follow it and
>>> understand why things are done the way they are.
>>>
>>> Col
>>>
>> I'm referring to runtime version resolution as opposed to statically
>> linked modules in the situation where it is believed the package
>> cannot run with the current module version.
>
> As should be clear by now, we are not talking about version resolution
> but alternative resolution.
>
> The Nvidia libGL.so.1 is not newer or older than the Mesa one, it's an
> alternative.
>
> If they were different versions we'd have to compile every single GL
> app in the distro specifically for Mesa and three Nvidia versions...
> this is clearly stupid and the current system of using alternatives
> works very well :)
>
> Col
>
Col,
  This was a discussion about a runtime dependency on libGL.so.1 as
opposed to a dependency on libGL.so and letting this link resolve to the
current version. Anssi was saying that from a Mandriva viewpoint, given
that if a module has a dependency on libGL.so.1 it is not compatible
with libGL.so.2, that it is better to have a runtime dependency on
libGL.so.1 rather than statically link it into the module. It was this
train of thought that I was saying made no sense to me. It makes more
sense to me to statically link this version into the module so that if
the package that provides libGL.so.1 gets upgraded to the package that
provides libGL.so.2, the module that requires libGL.so.1 would be
completely unimpacted. This to me is much more desirable than the
situation we are currently in where specific kde4 packages can't be
installed because 'no package provides libplasma.so.1'. The reason for
this failure is that libplasma1 (if that is what the package was called)
has been replaced by libplasma2 which provides libplasma.so.2. If the
kde4 packages were statically linked with libplasma.so.1, this upgrade
would have had no impact on them. This was the point I was trying to make.

regards,
Steve


Attachment: samorris.vcf (zipped)
©2008 redhatconfig.com - Jax Systems, LLC, U.S.A.