wine-wow64 and ia32-libs clash over libwine.so.1

[kjpetrie]

Pclos has an ia32-libs package which installs 32-bit libraries (mainly for Skype, I'm told) in /opt/libs32/. This package contains libraries needed by wine-wow64. It also contains a copy of libwine.so.1, one of the main libraries supplied by wine-wow64, which installs it in /usr/lib/.

The result is that two copies of this library get installed by wine, and ldconfig prefers the one in /opt/libs32/ over the one in /usr/lib/, causing wine to become confused over its version number and possibly causing some applications to segfault.

Unless ia32-libs can be upgraded every time one of the packages which owns one one of its libs is upgraded, we have a problem here, especially as it is not necessarily obvious to packagers that this other package contains a copy of a library they're packaging.

We need an authoritative steer around this problem, as it breaks Wine, and potentially any other application that needs 32-bit libs on a 64-bit system.

One suggestion I can think of is add the real 32-bit packages which own the files in ia32-libs to the 64-bit repo (in a separate section, perhaps?) and then make ia32-libs a meta package to install them all, but maybe there's a good reason not to do that.

[gseaman]

I think that you are treading in new territory, here. The best bet is to see what other distros are doing with 32 bit wine libs in 64 bit and tips from winehq. Ideally, all of the libraries in the ia32 package would be cross-compiled with their corresponding 64 bit versions. This is not exactly the same problem that you describe, but is related, I think. I suspect this is quite complicated to accomplish.

Galen

[kjpetrie]

What most other distros seem to do is produce 64-bit as a 'lol64' arrangement where everything is provided in dual architecture, so the 64-bit version of the OS is really a 32-bit system plus 64-bit when available. This means their full repo is available for 64-bit immediately without a need to build for 64, because the 32-bit packages can be installed and will run. Pclos, as I understand it, has decided to be a pure 64-bit OS (or as pure as it can be) and will only include 32-bit apps and libs where there is no alternative possible.

This means we need to know how to handle those exceptional cases, and it seems the initial response is the ia32-libs package, but that can clash with other lib32 packages if they share libraries, so I think we need a policy for handling this to ensure these conflicts don't arise and are handled. Texstar originally produced ia32-libs, but I don't know what his vision was or what the remedy should be. This is where we need an authoritative decision. We need someone with the right overview to supply a decision, so packagers can know the right thing to do. I lack the necessary knowledge to do any more than contribute where I can to that decision.