Bug-Report! wine-devel update becomes "amd64" =>PlayOnLinux fails

[=CO= Windler]

In Linux Mint 20.1 wine-devel updated itself to 9.18, but instead of a normal update, it forced to uninstall and replace itself with wine-devel (amd64). But PlayOnLinux now opens my very poorly working default version Wine 5.0, which crashes most things. On the tab "Wine-Versionen (amd64)" I get the error message "Wine packages website is unavailable".

E.g. graphics of VisualPinball 6 and 8 is messed up. Picture Publisher 8 crashes already when opening the file requester (previously crashed a bit later when clicking on a folder). IrfanView 32bit does not start at all anymore. It turned out that its "System" version was not found and so set to ancient wine 5.0.

I depend on PlayOnLinux because for production work I need multiple wine versions outside the devel stuff (particularly for emergency old wine that can run without 3D graphics driver).

PlayOnLinux lists its own wine versions from /home/aUserName/.PlayOnLinux/wine

The wine-devel folders seems to be

/opt/wine-devel/bin
wine
wine-preloader
wine64
wine64-preloader
/opt/wine-devel/wine/lib/
/opt/wine-devel/wine/lib64/

//opt/wine-devel/bin$ ls
wine wine64 wine64-preloader wine-preloader

$ ./wine --version
wine-9.17
$ ./wine64 --version
wine-9.18

I.e. "wine" seems the last old version. Only the wine64 versions seems to be updated but the system does not find them.

//opt/wine-devel/bin$ ls /usr/bin/wine*
/usr/bin/wine64-stable

/usr/bin$ ./wine64-stable --version
wine-5.0 (Ubuntu 5.0-3ubuntu1)

So I tested a symbolic link the new version.

/usr/bin$ sudo ln -s /opt/wine-devel/bin/wine64 /usr/bin/wine
/usr/bin$ wine --version
wine-9.18

sudo ln -s ./wine64-stable wine-stable
sudo ln -s /opt/wine-devel/bin/wine64-preloader /usr/bin/wine-preloader

/usr/bin$ ls wine*
wine wine64-stable wine-preloader wine-stable

PlayOnLinux now seems to find it as "System" version but Windoze programs loaded this way (e.g. VisualPinball 6) crash. Apparently this version can not run 32-bit code. 90% of my software is 32-bit and I can really live without 64-bit garbage than 32-bit mode.

I removed these symlinks again.

/usr/lib/wine/wine leads to the ancient wine 5.0, so linking that as wine-stable is not what I need.

/usr/bin$ sudo ln -s /opt/wine-devel/bin/wine ./wine
/usr/bin$ ./wine --version
wine-9.17

So that previous one would become System version, but programs stil crash, so I removed the symlink. What goes wrong?


I can not use a 64-bit-only version. Please urgently fix this.

[=CO= Windler]

According to aptitude, apparently the wine 32-bit version was in wine-devel-i386:i386, but the new version 9.18~focal-1 suddenly depends on a version of libbluray2 that damages its newer version 1:1:3:0-2~20.04.sav0 and so causes plenty of chain reactions. I don't intend to watch blurays (only burn data DVDs), so why should a windoze layer so stubbornly depend on this?! (Make this optional!)

I finally downgraded libbluray2 and subsequently libchromaprint1, so wine-devel-i386 seems to install again. The package winehq-devel sets it as the System version, so it seems to work again. (Into PlayOnLinux I locally loaded wine v9.0 (x86) as a fallback if 32-bit mode fails again.)