Ça fait quelques jours Ici, dans le blog, nous vous avons informé de la récente décision prise par les développeurs Ubuntu d'où la version 19.10, Ubuntu ne prendra plus en charge ni n'emballera pour l'architecture 32 bits. Avec l'arrivée d'Eoan Ermine, Ubuntu fermerait complètement l'architecture 32 bits.
Face à cette décision certains développeurs sont concernés puisque cette décision pourrait causer plus de problèmes que d'avantages au système, car elle a déjà conduit à la réponse de Wine à propos de laisser Ubuntu 19.10 sans support.
Et c'est que malgré le fait que ce mouvement n'est pas totalement inattendu, puisque les développeurs d'Ubuntu avaient précédemment déclaré qu'ils prendraient une décision à ce sujet.
Une fois qu'il est retourné, l'équipe d'ingénierie d'Ubuntu dit que:
"Nous avons examiné les faits dont nous sommes saisis et sommes arrivés à la conclusion que nous ne devrions pas continuer avec i386 en tant qu'architecture."
Will Cooke note que:
«Face à la forte possibilité que nous n'incluions pas i386 comme architecture de version sur 20.04 LTS, nous avons pris la décision proactive de désactiver les mises à jour du 18.04 au 18.10 pour les systèmes i386 afin d'éviter que les utilisateurs ne soient accidentellement bloqués sur une version intermédiaire de 9 mois. support, plutôt que de les laisser continuer à exécuter Ubuntu 18.04 LTS avec ses 5 ans de support standard.
Compte tenu de cela, les développeurs de Wine font partie de ceux qui ne sont pas satisfaits de la décision.
Les développeurs Wine contre l'abandon 32 bits dans Ubuntu
Le projet Wine exprime une critique massive du plan Ubuntu d'arrêter de proposer des packages 32 bits pour l'architecture x86 car cela posera beaucoup de problèmes pour le projet et les utilisateurs.
Depuis dans le vin Ils commentent qu'en cas d'abandon du support aux paquets 32 bits dans Ubuntu 19.04, ces versions d'Ubuntu et les suivantes qui continuent avec elle seraient officiellement laissées sans support pour Wine.
Et ce n'est pas par simple caprice des développeurs de Wine, mais que car les versions actuelles de Wine pour les distributions 64 bits sont basées sur Wine32 et nécessitent des bibliothèques 32 bits.
En règle générale, dans les environnements 64 bits, les bibliothèques 32 bits requises sont livrées dans des packages multiarchives, mais dans Ubuntu, il a été décidé d'arrêter complètement de créer de telles bibliothèques.
La raison en est assez facile à comprendre: de nombreuses applications Windows continuent d'utiliser du code 32 bits en tout ou en partie.
Cela doit être compatible avec le projet Wine pour pouvoir exécuter des applications Windows uniquement sous Linux.
Les développeurs Ubuntu voient cela un peu différemment et faites remarquer que de nombreuses applications pourraient fonctionner entre-temps, simplement avec la variante 64 bits de Wine.
Pour les autres programmes, L'équipe Ubuntu fait référence à la possibilité d'utiliser Ubuntu 18.04, qui est officiellement compatible avec l'architecture 32 bits jusqu'en 2023.
Cette version peut également être exécutée dans un conteneur. Avec une transmission de la technologie graphique vers le conteneur, les anciens jeux 32 bits peuvent continuer à fonctionner sur les versions actuelles d'Ubuntu.
Une façon de surmonter ces problèmes pourrait être d'utiliser la technologie multi-arches. dans les futures versions d'Ubuntu de l'architecture 64 bits.
Cela facilite l'utilisation des bibliothèques 32 bits comme environnement d'exécution dans la version 64 bits.
Une autre solution possible d'Ubuntu pour utiliser Wine 32 bits à l'avenir, qui consiste à publier des applications sous forme de snaps ou à utiliser un conteneur LXD basé sur Ubuntu 18.04 LTS qui a un accès complet à 32 bits multiarch WINE et aux bibliothèques associées, a également été discutée par le développeurs de Wine,
Bien que dans Wine, ils soutiennent qu'il n'est pas logique de mettre beaucoup d'efforts dans cette solution temporaire. Le responsable du référentiel Wine a également mentionné qu'il n'était pas intéressé à maintenir autant de bibliothèques.
De plus, il conseille de ne pas détourner son travail en proposant des solutions temporaires pour un système unique et pour des systèmes de package qui ne sont pas dans ses plans de maintenance.