Expliquez-moi le multiarch

Support Debian
#5

Salut

Une petite explication sur le blog de Carl Chenet

L’extrait du blog concernant le sujet :

[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]

Et le lien vers la liste de diffusion.

#6

J’ai fini (j’aurais du commencer par ça) par trouver LA page intéressante:

wiki.debian.org/Multiarch/TheCaseForMultiarch

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! :023
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:

Les NOUVEAUX paquets suivants seront installés : esound-common freeglut3:i386 gcc-4.7-base:i386 lesstif2:i386 libacl1:i386 libaio1:i386 libasound2:i386 libasyncns0:i386 libattr1:i386 libaudio2:i386 libaudiofile1:i386 libavahi-client3:i386 libavahi-common-data:i386 libavahi-common3:i386 libbsd0:i386 libc6:i386 libc6-i686:i386 libcaca0:i386 libcap2:i386 libcomerr2:i386 libcups2:i386 libcurl3:i386 libdb5.1:i386 libdbus-1-3:i386 libdirectfb-1.2-9:i386 libdrm-intel1:i386 libdrm-nouveau1a:i386 libdrm-radeon1:i386 libdrm2:i386 libedit2:i386 libesd0:i386 libexif12:i386 libexpat1:i386 libffi5:i386 libflac8:i386 libfltk1.1:i386 libfontconfig1:i386 libfreetype6:i386 libgcc1:i386 libgcrypt11:i386 libgd2-xpm:i386 libgdbm3:i386 libgl1-mesa-dri:i386 libgl1-mesa-glx:i386 libglapi-mesa:i386 libglu1-mesa:i386 libgnutls26:i386 libgpg-error0:i386 libgphoto2-2:i386 libgphoto2-port0:i386 libgpm2:i386 libgssapi-krb5-2:i386 libice6:i386 libidn11:i386 libieee1284-3:i386 libjbig0:i386 libjpeg62:i386 libjpeg8:i386 libjson0:i386 libk5crypto3:i386 libkeyutils1:i386 libkrb5-3:i386 libkrb5support0:i386 liblcms1:i386 libldap-2.4-2:i386 libltdl7:i386 liblzma5:i386 liblzo2-2:i386 libmpg123-0:i386 libncursesw5:i386 libnspr4:i386 libnspr4-0d:i386 libnss-ldap:i386 libnss3:i386 libnss3-1d:i386 libodbc1:i386 libogg0:i386 libopenal1:i386 libp11-kit0:i386 libpam-ldap:i386 libpam0g:i386 libpciaccess0:i386 libpng12-0:i386 libpopt0:i386 libpulse0:i386 librtmp0:i386 libsamplerate0:i386 libsane:i386 libsane-extras:i386 libsasl2-2:i386 libsasl2-modules:i386 libsdl1.2debian:i386 libselinux1:i386 libsigc++-2.0-0c2a:i386 libslang2:i386 libsm6:i386 libsndfile1:i386 libsqlite3-0:i386 libssh2-1:i386 libssl1.0.0:i386 libstdc++5:i386 libstdc++6:i386 libsvga1:i386 libsysfs2:i386 libtasn1-3:i386 libtdb1:i386 libtiff4:i386 libtinfo5:i386 libts-0.0-0:i386 libusb-0.1-4:i386 libuuid1:i386 libv4l-0:i386 libv4lconvert0:i386 libvorbis0a:i386 libvorbisenc2:i386 libvorbisfile3:i386 libwrap0:i386 libx11-6:i386 libx11-xcb1:i386 libx86-1:i386 libxau6:i386 libxaw7:i386 libxcb-glx0:i386 libxcb-render-util0:i386 libxcb-render0:i386 libxcb1:i386 libxcomposite1:i386 libxcursor1:i386 libxdamage1:i386 libxdmcp6:i386 libxext6:i386 libxfixes3:i386 libxft2:i386 libxi6:i386 libxinerama1:i386 libxml2:i386 libxmu6:i386 libxmuu1:i386 libxp6:i386 libxpm4:i386 libxrandr2:i386 libxrender1:i386 libxslt1.1:i386 libxss1:i386 libxt6:i386 libxtst6:i386 libxv1:i386 libxxf86vm1:i386 nscd odbcinst1debian2:i386 tcpd uuid-runtime xaw3dg:i386 zlib1g:i386

J’y vais ? :017

#7

Salut,

Si çà marche comme çà, pourquoi ne pas attendre que multi-arch soit mûr pour le cueillir ?

#8

[quote=“ggoodluck47”]Salut,
Si çà marche comme çà, pourquoi ne pas attendre que multi-arch soit mûr pour le cueillir ?[/quote]

Oui, mais si je suis en unstable + experimental c’est (en partie) pour aider Debian à avancer. Alors j’y vais! :smiley:

#9

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.

#10

Il va falloir que je m’y interesse de plus prét

#11

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.

#12

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.

EDIT: ha oui, et il y a un max de bug report avec les patchs fournis sur le sujet qui moisissent depuis des mois, par exemple : bugs.debian.org/cgi-bin/bugreport.cgi?bug=678040

S’en est déprimant.

#13

Je suit cette discussion :slightly_smiling:

#14

Salut,

Le “multiarch” est en phase de test. Sa place est bien en testing… 8)
Ceux qui ne souhaitent pas tester doivent rester en stable! :wink:

Il y aura peut-être du retard sur la future stable à cause de ça…

#15

Salut,

En dehors de “multiarch-support” qui m’a été installé en automatique et qui a validé les dépôts 386 que faut-il installer de plus ?

#16

[quote=“lol”]Le “multiarch” est en phase de test. Sa place est bien en testing… 8)
Ceux qui ne souhaitent pas tester doivent rester en stable! :wink:[/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 :smiley:

#17

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”… :wink:

#18

Salut,

Ceci est vrai sauf durant la période de freeze où l’on se contente de chasser le “bug”, non ?

#19

Ben je sais pas trop comment évolue unstable en période de freeze. :wink:
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. :slightly_smiling:

#20

Re,

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 !

#21

[quote=“syam”]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.[/quote]

Non mais c’est n’importe quoi la.

Il n’y a rien à tester sur ces paquets puisqu’il n’y a rien de fait.

Par exemple, le paquet libxvmc1 (dont je parle plus haut, mais il est pas tout seul). Il n’y a rien de fait vis à vis du multiarch. Ça sert à rien de tester, il n’y a rien à tester, le paquet est exactement le même depuis des lustres, depuis avant le multiarch en fait. Il a jamais été touché.

Le problème est connus depuis le début du multiarch (donc depuis des mois) il n’y a qu’un flag à la con à mettre dans control/control pour que ça marche (la lib en elle même marche très bien, c’est bien le paquet qui ne va pas) et la seule réponse des mainteneur dans le bug report c’est « ça fait merde wine et les pilotes nvidia, donc je m’en branle » (traduction par mes soins).

Encore une fois, il n’y a rien à tester, puisque il n’y a rien de fait. Enfin bon, contourner le problème est en général pas compliqué : forger un paquet à la main en modifiant la version et ajoutant le fameux flag pour le multiarch.

#22

[quote=“syam”]Quand on se tue à dire que testing est très loin d’être une “presque stable”… :wink:[/quote]Et qu’on se fait engueuler à cause de ça… :005

#23

Bonjour,

ça y est, j’ai compris! et après ça se pose en stable où ça met le queens :041

@+

#24

ça y est, j’ai compris! et après ça se pose en stable où ça met le queens :041

C’est agréable de t’expliquer quelque chose, on sent que tu suis bien les explications qui te sont données :laughing: