Bug#685054: Break wine opengl support on amd64

[Andreas Beckmann]

On 2012-08-16 11:33, Klaus Ethgen wrote:
> Am Do den 16. Aug 2012 um 10:15 schrieb Andreas Beckmann:
>>> There is a note about the multiarch-stuff.
> 
>> the old monolithic ia32-libs needs to go away as it ships
>> lib32/libGL.so.1 and nvidia driver no longer diverts this
> 
> I read that. However, it worked well in older versions of nvidia. I am
> with you that shipping that file in ia32-libs might be a mistake.

shipping anything in ia32-libs is a mistake :-) so I decided to conflict
with the ia32-libs that ships stuff instead of continuing to divert it
(since I don't provide any replacement in /usr/lib32)

>>> But if I fulfil this and
>>> activate multiarch, there will be installed many packages that I never
> 
>> you are upgrading from the monolothic ia32-libs to the transitional one
>> - that pulls in many :i386 packages - you probably have something
>> depending on ia32-libs, otherwise you could remove this package with its
>> lots of dependencies
> 
> I can deinstall it but it will always be installed with dist-upgrade
> again. This is moreover annoying as I have lowered recommends to
> suggests by apt config on my system exactly for cases like this.

> I do not find the package that makes apt installing that annoying
> packages ever and ever again. But this seems to be an other problem.

interactive aptitude may be better suited to analyze these dpendency
scenarios

>>> Beside that, I tried that but it has merely the same effect.
>>> But now wine will fail to run completely.
> 
>> But this is the way to go. Your self compiled wine is not compatible
>> with multiarch stuff
> 
> I thought that too so I did try the distribution wine but failed to get
> it working.

Either you found a bug or you need to try harder ... the wine
maintainers might help here

> However, there is two issues that force me to compile wine myself. First
> I need a much newer version of wine or even wine-unstable (By the way
> the upstream stable is much newer than the debian unstable).

> Second I
> need a small patch. Without this patch, wine is buggy on non-KDE or
> non-Gnome window managers.

Did you report a bug?

>> and the new nvidia drivers are no longer compatible
>> with the old ia32-libs mess.
> 
> So it breaks possible many applications, including several proprietary
> ones. (One getting in my mind is TSM.) There must be a way to have
> legacy stuff running.

multiarch will be problematic for proprietary stuff - or easier if you
can just use a :i386 package which pulls in multiarch libs instead of
having a :amd64 package with i386 binaries depending on biarch and
ia32-libs mess ...

>> Probably these are the steps you need to take:
>> * get rid of ia32-libs
> 
> It worked for ages now. However, I know it is a hack.

it worked as in "ia32-libs worked" or "removing ia32-libs worked" ?

and that hack (aka monolithic ia32-libs) is finally going away

>> * get wine:i386 running (I think that is the way nowadays, check the
>> wine documentation)
> 
> Will not work as I mention above.

If you need it patched and updated for running $YOUR_APPLICATION that
doesn't mean you can't try to get the Debian wine packages running for
some other trivial application - just to see if you got the multiarch
libs right. Once that is working go back to compiling your own wine.

>> * get nvidia support in wine
> 
> Wrong point for that. Wine include OpenGL and this is how it should
> work.

Bad wording on my side. Once you have a running wine, start looking into
the Nvidia OpenGL issue. Nothing to be fixed in wine itself.

> There must be an other solution. We are running in the situation where
> we are pushed back fifteen years of time in amd64 support!

First we need to get the packages in Debian working properly -
thereafter we can look into local software or third party packages.


Andreas