http://bugs.winehq.org/show_bug.cgi?id=58738
Bug ID: 58738 Summary: debian packages and wow64 Product: Packaging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-packages Assignee: wine-bugs@winehq.org Reporter: info@fernandolucas.info CC: dimesio@earthlink.net Distribution: ---
So far it seems that the Debian packages are built without the wow64 support? Is this right? If so, in view of the wine 11 release, allowing the wow64 mode in the packages would be a great step forward.
There is the step of the hardcoded dependency into the i386 packages. I have workaround this with a local dummy package,
printf "Package: wine-devel-i386-dummy Version: %s Architecture: all Provides: wine-devel-i386 (= %s) Conflicts: wine-devel-i386 Replaces: wine-devel-i386 Maintainer: Dummy Maintainer noreply@example.com Description: Dummy package to satisfy wine-devel-i386 dependency This is a placeholder package that pretends to be wine-devel-i386. " "$VERSION" "$VERSION" > wine-devel-i386-dummy_${VERSION}/DEBIAN/control
I install this package first, and then I can install wine-devel and winehq-devel without complaining about dependencies. It would be ideal if the repositories also provide something such as wine-devel-i386-dummy in the release process and document that by installing it, the win32 dependency is avoided.
http://bugs.winehq.org/show_bug.cgi?id=58738
--- Comment #1 from Rosanne DiMesio dimesio@earthlink.net --- Our Debian and Ubuntu packages are still "old WoW64" builds, so yes, they require installing the i386 packages along with the amd64 ones. While your dummy packages may satisfy the installer, they will also break any apps that require the 32 bit libraries under old WoW64.
I have thought about switching to "new WoW64" packages for newer versions of Debian and Ubuntu, and probably will do so at some point. However, I do not plan to switch over the packages for existing distros, as new WoW64 does not work at all with 32 bit wineprefixes, and many of our users have those.
http://bugs.winehq.org/show_bug.cgi?id=58738
--- Comment #2 from Fernando info@fernandolucas.info --- I have not tried to recompile from the source, and try the multiple combinations of the flags, so I apologize if I was/am not understanding well.
Is activating wow64 support in wine64 blocking the capabilities of using win32 prefixes? I was understanding that enabling wow64 flag will not break win32 prefixes, and user can choose win32,win64,wow64 in a multiarch setup. But debian packages were not build with this new flag.
So a build of the current packages with that flag would not break anything.
---> Is assumption this correct??
If so.... In the case that I want to fully remove dependencies to the i386 architecture .... I can have my dummy package, I install it before doing sudo apt install --install-recommends winehq-devel and I know that win32 prefixes are broken, but I can use wow64
this approach would break nothing in general, the current package installations would not break.
The documentation can explain that if the user wants win32 prefix, the i386 architecture is needed, and follow the current documentation.
But also mention that if a user wants to avoid i386 and multiarch, install the dummy package of i386, beforehand, and then winehq-devel. The win32 prefixes will fail, but can try wow64
http://bugs.winehq.org/show_bug.cgi?id=58738
--- Comment #3 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Fernando from comment #2)
So a build of the current packages with that flag would not break anything.
---> Is assumption this correct??
No. "New WoW64" builds cannot create or use a 32 bit wineprefix. They can't run 16 bit apps at all, and have performance issues with 32 bit OpenGL apps.
If so.... In the case that I want to fully remove dependencies to the i386 architecture .... I can have my dummy package, I install it before doing sudo apt install --install-recommends winehq-devel and I know that win32 prefixes are broken, but I can use wow64
You are free to do whatever you want on your own system. Our packages are aimed at the general, nontechnical user, who is unlikely to read the documentation at all.