(Solved) How the Latest Wine-Staging Release, for Debian, Introduces a Packaging Problem: Unresolved Dependencies.

One piece of software which many Linux users benefit from is called “Wine”, which is an acronym that stands for ‘Wine Is Not an Emulator’ . This software allows some Windows programs to run under Linux, but has recently been made more powerful, to allow graphics-intensive games to run as well. The version of wine which I’ve been subscribing to is called ‘wine-staging’ , and contains the latest, bleeding-edge features that Wine is to contain, at any later point down the road.

But as I’ve been receiving updates to wine-staging, the latest update would have taken all my computers from version 4.0-rc2, to version 4.0-rc4, which means, ‘…Release Candidate 4′ . At that point, some of my computers could not install the update, because of unresolved package dependencies.

Apparently what’s been happening with Wine-Staging is twofold:

1. The original maintainers are no longer running the project, which also means that Wine is in the midst of a Code Freeze, and that present updates may offer fewer or no new features, from what Linux users are used to, and
2. In the interest of allowing the Windows games with the highest graphics requirements to run (potentially), the devs have nevertheless created a dependency of the latest Wine packages, on the OpenCL packages that install OpenCL natively under Linux.

‘OpenCL’ is a user-side API, which also requires system-side drivers for the specific graphics hardware, and which allows greatly parallel computations to be carried out on the GPU, instead of on the CPU. Apparently, some games use either ‘OpenCL’ or ‘CUDA’ these days, in order to incorporate complex Physics simulations into the game.

(I will assume that the version of CUDA which Wine emulates, requires OpenCL to be installed on the side of Linux.)

The problem under Debian which I’ve detected is, that the newly-introduced dependency of ‘wine-staging-amd64′ (as an example) is simply mainly:

‘ocl-icd-libopencl1′

Which means, that Wine will now insist on using the generic OpenCL drivers, that were developed for and by the Linux community, while not allowing the use of proprietary OpenCL drivers, that are closed-source, and that were developed by the manufacturers of each graphics card.

The problem with this is, that as users, we may only have one or the other OpenCL driver-set installed. We cannot install both the generic and the proprietary drivers. When we try to update Wine-Staging now, doing so will try to install the package above, which will also try to ‘kick out’ , any proprietary packages we may have installed, that provide OpenCL.

This really just constitutes a packaging error, under Debian. Instead of depending on that one package, the newer Wine versions could just depend on any one package out of the following list:

• ‘ocl-icd-libopencl1′
• ‘nvidia-libopencl1′
• ‘amd-opencl-icd’
• ‘amd-opencl-icd-legacy’

If the Wine developers had simply made this the definition of the new dependency, there would be no conflict.

However, one fact which I’ve already blogged about, is that On those computers which are capable of supporting OpenCL, only the proprietary drivers actually work for me. It therefore makes no sense for me whatsoever, to uninstall the only OpenCL version that works, just so that I can update to the latest version of Wine-Staging.

And I’m hoping that the new maintainers eventually realize, how the packages are organized under Debian, so that they can fix their error.

Solution, on my NVIDIA-equipped computer named ‘Plato’ :

As root, I needed to run:


#apt-get install nvidia-libopencl1:i386



Explanation :

As an alternative to depending on the first package which this posting names, ‘wine-staging-amd64′ actually depended on the virtual package:

‘libopencl1′

This package is called a virtual package because there is actually no package in the repositories, by that name. Instead, the individual providers of OpenCL may include in the meta-data of one of their packages, the fact that their package provides ‘libopencl1′ , using the Keyword “Replaces”.

Additionally, my Wine versions are Multi-Arch, which means that they aim to provide compatibility for both 32-bit and 64-bit Windows, which requires native, 32-bit as well as 64-bit (Linux) libraries to be installed. Well just as there existed a new dependency on the 64-bit version of this package, the package ‘wine-staging-i386:i386′ stated an analogous dependency on the 32-bit version, of this virtual package. This missing dependency was preventing the whole bundle of Wine packages from updating. The command above provided that, at which point I was also able to upgrade to Release Candidate 4 of Wine-Staging, v4.0 .

Solution, on my ATI-equipped laptop named ‘Klystron’ :

As root, I ran:


#apt-get install amd-libopencl1:i386



Explanation :

Same as above.

Caveat :

I suppose that this discovery implies, that if users want to install Wine 4.0, RC-4 or greater in the future, in order to do so properly, they’ll need to install OpenCL first. If they don’t, then the package-manager will do so for them, and in that case, they may end up with a version of OpenCL installed, which they don’t want, or which doesn’t work for them (the generic version).

Also, I find it to be an important observation that even though I, personally tend to install the 64-bit base system first, and then to install 32-bit interfaces to it spot-wise, the world of gaming for Windows still works largely with 32-bit interfaces to DirectX, to CUDA, etc..

Dirk

This site uses Akismet to reduce spam. Learn how your comment data is processed.