Das ist wirklich eine Beschönigung. Unter Windows ist 32 bit noch sehr präsent. Hinzu kommt, dass man bei Wine oftmals auf die 32-bit-Variante zurückgreifen muss, obwohl es eine 64 bit-Version gibt, weil man dann doch irgendwas mit Winetricks (dotnet etc.) nachinstallieren muss und das sehr oft nur mit den nativen 32 bit-Bibliotheken reibungslos funktioniert. Hinzu kommt, dass es nicht unbedingt heißt, dass alles 64 bit ist, wenn das beim Hauptprogramm der Fall ist. Da gibt es tausend Variationen in der Welt von WoW64.
Wenn du dir das 64 bit-Wine aus dem repo ziehst, brauchst du imho keine 32 bit-Bibliotheken für 32 bit-Anwendungen. Wenn du Wine aber bauen musst, bist du darauf angewiesen auch eine 32 bit-Wine-Version zu kompilieren. Dass ist auch heute unter Ubuntu schon recht aufwändig und muss im lxd-Container/schroot passieren - allerdings nur der Build des 32 bit-Wine-Anteile. In der Anwendung braucht man das nicht. Und der Build wird natürlich auch irgendwann problematisch, wenn man als lxd-Container nur noch 18.04 möglich ist und man regulär 20.04,20.10 installiert hat. Da wird es irgendwann zu Problemen kommen und man ist wirklich darauf angewiesen das ganze komplett im lxd-Container mit altem Ubuntu laufen zu lassen.
Ich hoffe, dass ich das einigemaßen richtig zusammengefasst habe. Vielleicht können das Experten noch ein wenig ausführen und ggf. korrigieren.
Da muss ich mich selbst anscheinend korrigieren. Auch für das reine Anwenden braucht es die libs in Ubuntu. Da ein reines Wine 64 bit relativ sinnlos ist, wird sich hoffentlich eine "einfache"/automatisierte Containerlösung finden. Das läuft dann wohl auf ein Ubuntu 19.04 oder 18.04 wegen des LTS als Container hinaus in dem dann quasi alles läuft, da Trennung so unpraktikabel. Bin mal gespannt, wie ob sie da eine gescheite Lösung finden.
In jedem Fall alles umständlich und unerfreulich. Die reine 32 bit-Hardware, die man damit nicht mehr bedient, ist wahrscheinlich wirklich eher das kleinere Problem bei diesem Schritt.
Deine erste Antwort (dass man die 32-bit-libs fürs schlichte Anwenden von wine32 nicht braucht) widersprach meinen eigenen Erfahrungen und hatte mich daher etwas gewundert.
Es gibt jetzt auch auf der wine mailing list eine Diskussion zu dem Thema. https://www.winehq.org/pipermail/wine-devel/2019-June/147869.html
Der Tenor ist, dass die Leute bei Ubuntu gar nicht wirklich erfassen, wie das mit Wine wirklich gelagert ist. Man sieht eigentlich überhaupt keinen Sinn in reinen 64 bit-Paketen. Ich habe ja schon geschrieben, dass 32 bit noch sehr verbreitet ist, dass man u.a. aufgrund von winetricks auf die 32 bit-Version zurückgreifen muss und dass es viele Mischungen gibt. Das wir dort noch mal konkretisiert. Praktisch ist quasi jedes Installationsprogramm für 64 bit-Versionen in 32 bit umgesetzt, damit es unter 32 bit-Windows kontrolliert ablaufen kann (und z.B. darauf hinweist, dass die Version für diese Windows-Version nicht ausgelegt ist) https://www.winehq.org/pipermail/wine-devel/2019-June/147874.html
Also kann man selbst für absolut reinrassige 64 bit-Anwendungen nichts mit einem 64 bit-Wine anfangen außer es sind Sonderfälle, die nur gezippt sind o.ä.
Das ist wirklich eine Beschönigung. Unter Windows ist 32 bit noch sehr präsent. Hinzu kommt, dass man bei Wine oftmals auf die 32-bit-Variante zurückgreifen muss, obwohl es eine 64 bit-Version gibt, weil man dann doch irgendwas mit Winetricks (dotnet etc.) nachinstallieren muss und das sehr oft nur mit den nativen 32 bit-Bibliotheken reibungslos funktioniert. Hinzu kommt, dass es nicht unbedingt heißt, dass alles 64 bit ist, wenn das beim Hauptprogramm der Fall ist. Da gibt es tausend Variationen in der Welt von WoW64.
Wenn du dir das 64 bit-Wine aus dem repo ziehst, brauchst du imho keine 32 bit-Bibliotheken für 32 bit-Anwendungen. Wenn du Wine aber bauen musst, bist du darauf angewiesen auch eine 32 bit-Wine-Version zu kompilieren. Dass ist auch heute unter Ubuntu schon recht aufwändig und muss im lxd-Container/schroot passieren - allerdings nur der Build des 32 bit-Wine-Anteile. In der Anwendung braucht man das nicht. Und der Build wird natürlich auch irgendwann problematisch, wenn man als lxd-Container nur noch 18.04 möglich ist und man regulär 20.04,20.10 installiert hat. Da wird es irgendwann zu Problemen kommen und man ist wirklich darauf angewiesen das ganze komplett im lxd-Container mit altem Ubuntu laufen zu lassen.
Ich hoffe, dass ich das einigemaßen richtig zusammengefasst habe. Vielleicht können das Experten noch ein wenig ausführen und ggf. korrigieren.
Da muss ich mich selbst anscheinend korrigieren. Auch für das reine Anwenden braucht es die libs in Ubuntu. Da ein reines Wine 64 bit relativ sinnlos ist, wird sich hoffentlich eine "einfache"/automatisierte Containerlösung finden. Das läuft dann wohl auf ein Ubuntu 19.04 oder 18.04 wegen des LTS als Container hinaus in dem dann quasi alles läuft, da Trennung so unpraktikabel. Bin mal gespannt, wie ob sie da eine gescheite Lösung finden.
In jedem Fall alles umständlich und unerfreulich. Die reine 32 bit-Hardware, die man damit nicht mehr bedient, ist wahrscheinlich wirklich eher das kleinere Problem bei diesem Schritt.
OK, danke für die Korrektur.
Deine erste Antwort (dass man die 32-bit-libs fürs schlichte Anwenden von wine32 nicht braucht) widersprach meinen eigenen Erfahrungen und hatte mich daher etwas gewundert.
Es gibt jetzt auch auf der wine mailing list eine Diskussion zu dem Thema. https://www.winehq.org/pipermail/wine-devel/2019-June/147869.html
Der Tenor ist, dass die Leute bei Ubuntu gar nicht wirklich erfassen, wie das mit Wine wirklich gelagert ist. Man sieht eigentlich überhaupt keinen Sinn in reinen 64 bit-Paketen. Ich habe ja schon geschrieben, dass 32 bit noch sehr verbreitet ist, dass man u.a. aufgrund von winetricks auf die 32 bit-Version zurückgreifen muss und dass es viele Mischungen gibt. Das wir dort noch mal konkretisiert. Praktisch ist quasi jedes Installationsprogramm für 64 bit-Versionen in 32 bit umgesetzt, damit es unter 32 bit-Windows kontrolliert ablaufen kann (und z.B. darauf hinweist, dass die Version für diese Windows-Version nicht ausgelegt ist) https://www.winehq.org/pipermail/wine-devel/2019-June/147874.html
Also kann man selbst für absolut reinrassige 64 bit-Anwendungen nichts mit einem 64 bit-Wine anfangen außer es sind Sonderfälle, die nur gezippt sind o.ä.