Salut,
j’ai eu beau lire les différents posts traitant ce sujet, je ne comprend pas de quoi il retourne (enfin, presque pas…).
Si j’ai bien compris, il s’agit d’installer des paquets compilés pour i386 dans un système amd64.
C’était déjà le cas avec la librairie ia32-libs non ?
Il est précisé pour ia32-libs [quote]This package requires multiarch to be enabled before it can be
installed, use “dpkg --add-architecture i386”.[/quote]
Je suppose que ça se fait automatiquement, ia32-libs s’est automatiquement installé avec googleearth ?
Comment vérifier que le support pour des paquets i386 est activé ?
Quel est l’enjeu du multiarch ?
Evidemment comme tout le monde ia32-libs ne peux plus être mis à jours depuis un certain temps sans casser d’autres paquets. Situation temporaire ?
Le Multiarch sert à faire fonctionner une application i386 sur un système amd64.
Concernant le paquet ia32-libs, il est passé en statut “oldlibs” sur packages.debian.org donc il disparaîtra complètement lorsque le Multiarch sera totalement introduit dans Debian.
[quote]Support des architectures multiples dans Debian
Le but est de supporter la coexistence de bibliothèques dans des architectures différentes sur le même système de fichiers, le cas d’exemple le plus commun est la coexistence des bibliothèques pour les architectures i386/amd64. Cette fonctionnalité est maintenant présente dans Debian Sid, et se caractérise très concrètement par l’existence d’un répertoire /lib/$arch dans lequel seront présents les bibliothèques partagées, les paquets contenant ces dernières devant être modifiés pour s’adapter. Le travail d’adaptation est en cours, 63 paquets source ont déjà été convertis. Il reste néanmoins beaucoup de travail, et en particulier au niveau de la gestion de l’architecture multiple pour apt et dpkg.[/quote]
Les enjeux sont plus larges que le simple portage de paquets i386 dans amd64.
Si j’ai bien compris (encore une fois) fini le bricolage: il s’agit carrément de proposer une architecture commune pour les librairies.
C’est prometteur!
Un paquet compilé sur i386 s’installerait comme une fleur sur un amd64;
Plus de re-compilation nécessaire pour les binaires.
Le passage, sur ma machine impose cette installation:
Moi j’y suis allé (sid + experimental).
Mais c’est pas encore tout à fait au point.
Notamment, il y a un bug qui empêche le logiciel wine de s’installer
(de se compiler). Playonlinux p.ex. ne marche plus très bien.
Voir notamment http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684776
Si tu utilises wine, vaut mieux éviter pour l’instant.
Je viens apporter mon point de vue sur ce sujet,
tout d’abord je suis en debian SID amd64.
Je suis passé au multiarch, suite au passage de la suite ia32,
dans oldlibs, et surtout à la dernière mise à jour de nvidia-glx (j’utilise dkms).
Alors cela marche bien, mais evidement il y a encore certains paquets qui demandent a etre patchés et recompilés, pour pouvoir fonctionner en multiarch.
[quote=“guyr34”]Moi j’y suis allé (sid + experimental).
Mais c’est pas encore tout à fait au point.
Notamment, il y a un bug qui empêche le logiciel wine de s’installer
(de se compiler).[/quote]
Pour ma part j’utilise wine-unstable 1.5.6, et j’ai eu aussi un problème, en débarquant dans le multiarch, mais pas du coté de wine, mais de celui du pilote, nvidia.
N’utilisant plus ia32-libs, j’ai du installer, les dépendances i386 requisent pour wine, bref, principalement libgl1-nvidia-glx requis en version i386 pour wine et amd64, pour xorg, donc installer les deux, ce qui est rendu possible par le multiarch et, si on patche/recompile, le paquet libxvmc1 qui lui n’etait pas encore mis à jour pour le multiarch (bug : bugs.debian.org/cgi-bin/bugreport.cgi?bug=640499), et la tout fonctionne niquel.
Ouai, alors le multi arch, c’est pas franchement au point encore.
Ça fait des moi que j’ai des problèmes avec (particulièrement lorsque que je compile GCC moi même, ce qui m’arrive souvent car je travaille sur D). Je n’ai jamais réussit à avoir une compil qui va récupérer les trucs dans les bons dossiers.
Mais la blague ne s’arrête pas la. Depuis peu, la 3D ne fonctionne plus avec les cartes nvidia en 32bit sur du amd64. Le paquet qui contient libGL est passé en multilib mais pas toutes ses dépendances (vous allez avoir des soucis avec xvmc). Allez, je vous envoie le tips, ça a été fait pour nous : twolife.be/debian/todo/xvmc/ vous avec les .deb en multiarch ici.
Ceci dit, je ne sais pas quoi faire des paquets dev relatifs à mesa, ce qui fait que je ne peut pas compiler avec openGL en 32bits.
Encore mieux, ia32-libs contient aussi une version de libGL . . . bugguée. Et bien entendu, ld.so charge cette lib en premier, quelque soit la conf que je lui fournis (je n’ai pas compris pourquoi). Si vous voulez un bon conseil, une fois des paquets multiarch installés, allez blaster la lib correspondante dans /usr/lib32 sans quoi c’est la galère assurée.
Je ne sais pas ce qui a pris aux mainteneur de pousser ça en testing. C’est vraiment bien, mais c’est pas encore prêt. C’est pas la politique habituelle de debian.
[quote=“lol”]Le “multiarch” est en phase de test. Sa place est bien en testing…
Ceux qui ne souhaitent pas tester doivent rester en stable! [/quote]
Une grande partie des paquets ne sont pas prêt pour le multi arch. Il n’y a rien à tester, c’est pas prêt.
La ça n’aurait pas du dépasser sid, surtout quand on voit le nombre de problème connus avec des patchs et qui ne sont pas dans les dépôts depuis des mois.
ggoodluck47 > Tu es en multiarch. Tu ne le saura pas, jusqu’au moment ou tu auras à subir
Tu es certain d’avoir compris comment testing fonctionne ? Personne n’a fait descendre le multiarch dans testing pour la simple et bonne raison que la propagation des paquets se fait de manière automatique, en suivant des règles pré-établies et bien précises. À partir du moment où ça rentre dans unstable, ça atterrit fatalement dans testing pas longtemps après, de manière entièrement automatisée. Et tant pis si ça fout le bronx.
Comment veux-tu savoir qu’ils ne sont pas prêts si le support multiarch n’est pas disponible en test pour pouvoir identifier les problèmes ?
Et comment tester ceux qui sont prêts ?
Contrairement à ce que tu sembles croire, c’est précisément un des buts de testing : avoir un environnement un peu moins mouvant qu’unstable pour pouvoir se rendre compte de ce genre de problèmes.
Avec les grosses migrations architecturales comme celle-là, faut savoir prendre son mal en patience. Et si l’état actuel de testing ou d’unstable te pose problème, il faudrait te demander si testing ou unstable (avec tous les inconvénients qui vont avec, y compris des bugs et instabilités qui durent longtemps) sont réellement adaptées à ton usage.
Quand on se tue à dire que testing est très loin d’être une “presque stable”…
Ben je sais pas trop comment évolue unstable en période de freeze.
J’ai beau avoir un certain nombre de paquets qui viennent d’unstable je fais jamais trop attention d’où viennent les paquets précisément lors d’une mise à jour, je fais confiance à mes pinnings pour ça.
Tu es beaucoup mieux placé que moi pour savoir si unstable continue à bouger comme à son habitude (auquel cas effectivement c’est la “descente” des paquets vers testing qui est bloquée) ou bien si c’est très calme et que les seules nouveautés sont justement les corrections de bug destinées à testing.
Dans les deux cas, pour la discussion qui nous concerne, le support multiarch est arrivé bien avant le freeze, à un moment où la propagation unstable/testing était normale. Selon snapshot.debian.org ça date de juin… 2011.
La sid est on ne peut plus mouvementée pendant les périodes de freeze puisque les développeurs essayent de corriger rapidement tous les bugs signalés, ce qui peut parfois donner plus de 30 paquets chaque matin.
Il y a donc intérêt à ne pas se laisser déborder, sous peine de gros problèmes. Je n’ai jamais essayé de rester huit jours sans upgrade comme le font certains !
entre autre! Ceci malgré 
… 
