C'est comme ça depuis longtemps. Ce n'est pas nouveau. Toi tu dis que c'est nouveau. C'est sur ce point que je ne suis pas d'accord.
Par exemple, "rpm-libs" est apparu avec rpm 4.2.3. Bon, après, on peut effectivement interpréter "longtemps". bzip2-libs existe par exemple depuis GinGin64 effectivement.
De plus j'aimerai que tu me trouves ce code rpm.
Je parle de rpm, c'est pourtant marqué en clair dans les commentaires, et très lisible dans les sources.
Si tu fais "rpm -i toto...i386.rpm toto...x86_64.rpm", il les installera s'il ne sont pas en comflit.
En cas de conflit, et vu que tu spécifies les 2 packages sur la même ligne de commande, rpm ignorera les conflits et installera les binaires elf64 qu'il trouve. Bien sûr, d'autre conflits peuvent survenir (/usr/share/*), dans ce cas là, ça conflicte réellement. La résolution des conflits elf64/elf32 est transparente. C'est pas forcément une bonne chose (cf. plus bas) mais ça fonctionne.
Ça dépend. Pour les lib, ça ne "conflict" pas.
Pourvu que tu n'aies pas de /usr/share/doc/ par exemple qui diffère d'un chouia. Avec une approche où le package de libs s'appelle différemment, tu ne peux pas avoir de conflit pour les docs par exemple.
- "sans conflit lors de l'installation (non simultanée) desdits packages."
Où veux tu en venir ?
En simultané (rpm -i truc.i586.rpm truc.x86_64.rpm), c'est naturel, ça marchera quasiment tout le temps avec la résolution de conflicts implicite entre elf32/elf64 et du fait que tu spécifies une même version-release dans les 2 cas. Par non simultanée, j'entends que tu installes plus tard. i.e. pas sur la même ligne de commande, i.e. ça peut être une version-release différente mais dans la vraie vie l'utilisateur voudra avoir une installation cohérente des libs 32-bit et 64-bit de toutes façons.
Deuxième chose, installer c'est bien, pouvoir mettre à jour c'est mieux. Et là, le système de résolution de conflits implicite est moins flexible.
Par quel miracle il est possible d'installer lib64glib2.0._0-devel avec libglib2.0_0-devel alors qu'il y a des fichiers en conflit ?
D'une part, tu as une manière typiquement de toi et magistrale de contourner les réponses. Tu peux changer de pseudo, on te reconnaîtra tout le temps. ;-) J'ai dit "glib-devel", tu regardes correctement et tu réalises que c'est glib 1.2. D'autre part, dans le cas de glib2.0-devel, les conflits sont ignorés car les binaires glib-genmarshal et gobject-query sont marqués elf64 donc préférés à l'install. i.e. si tu installes la version 32-bit après la 64-bit, l'ancien binaire 64-bit est conservé.
Par ailleurs, je n'aime pas trop ce système de résolution implicite des conflits rpm à préférer par défaut les binaires 64-bit sans warning. Justement parce que c'est implicite, tu ne sais plus qu'il existait un conflit potentiel. C'est assez dangereux pour des générateurs car le code (source C par exemple) peut devoir être différent suivant que tu veux du 32-bit ou 64-bit. Heureusement, qu'on vérifie ce genre de choses. Le cas de glib2.0-devel a l'air sain i.e. ces 2 binaires sont censés être arch-indépendants (c'est pour générer du code faisant du marshaling).
Dans le cas où des binaires, ou bien des includes, ont un comportement différent suivant que tu veux du 32-bit ou 64-bit, Mandriva Linux a tout un dispositif pour différencier cela automatiquement (sauf pour le packager mais il existe des outils pour essayer de vérifier cela statiquement au build). De fait, tu as par exemple /usr/bin/multiarch-i386-linux/glib-config et /usr/bin/multiarch-x86_64-linux/glib-config. Tu vois clairement que différencier les 2 est important car --cflags doit fournir des résultats différents suivant que tu buildes du 32-bit ou 64-bit. Pareil pour les includes, e.g. #define QT_POINTER_SIZE 4 ou 8.
Au final, tu peux rebuilder des packages 32-bit aussi simplement que linux32 rpm --rebuild evolution.rpm (pour avoir du i586.rpm) ou rpm --rebuild evolution.rpm (pour avoir du x86_64.rpm).
[^] # Re: Et le plus important...
Posté par Gwenole Beauchesne . En réponse au journal Mandriva Linux Limited Edition 2005 released. Évalué à 2.
Par exemple, "rpm-libs" est apparu avec rpm 4.2.3. Bon, après, on peut effectivement interpréter "longtemps". bzip2-libs existe par exemple depuis GinGin64 effectivement.
De plus j'aimerai que tu me trouves ce code rpm.
Je parle de rpm, c'est pourtant marqué en clair dans les commentaires, et très lisible dans les sources.
Si tu fais "rpm -i toto...i386.rpm toto...x86_64.rpm", il les installera s'il ne sont pas en comflit.
En cas de conflit, et vu que tu spécifies les 2 packages sur la même ligne de commande, rpm ignorera les conflits et installera les binaires elf64 qu'il trouve. Bien sûr, d'autre conflits peuvent survenir (/usr/share/*), dans ce cas là, ça conflicte réellement. La résolution des conflits elf64/elf32 est transparente. C'est pas forcément une bonne chose (cf. plus bas) mais ça fonctionne.
Ça dépend. Pour les lib, ça ne "conflict" pas.
Pourvu que tu n'aies pas de /usr/share/doc/ par exemple qui diffère d'un chouia. Avec une approche où le package de libs s'appelle différemment, tu ne peux pas avoir de conflit pour les docs par exemple.
- "sans conflit lors de l'installation (non simultanée) desdits packages."
Où veux tu en venir ?
En simultané (rpm -i truc.i586.rpm truc.x86_64.rpm), c'est naturel, ça marchera quasiment tout le temps avec la résolution de conflicts implicite entre elf32/elf64 et du fait que tu spécifies une même version-release dans les 2 cas. Par non simultanée, j'entends que tu installes plus tard. i.e. pas sur la même ligne de commande, i.e. ça peut être une version-release différente mais dans la vraie vie l'utilisateur voudra avoir une installation cohérente des libs 32-bit et 64-bit de toutes façons.
Deuxième chose, installer c'est bien, pouvoir mettre à jour c'est mieux. Et là, le système de résolution de conflits implicite est moins flexible.
Par quel miracle il est possible d'installer lib64glib2.0._0-devel avec libglib2.0_0-devel alors qu'il y a des fichiers en conflit ?
D'une part, tu as une manière typiquement de toi et magistrale de contourner les réponses. Tu peux changer de pseudo, on te reconnaîtra tout le temps. ;-) J'ai dit "glib-devel", tu regardes correctement et tu réalises que c'est glib 1.2. D'autre part, dans le cas de glib2.0-devel, les conflits sont ignorés car les binaires glib-genmarshal et gobject-query sont marqués elf64 donc préférés à l'install. i.e. si tu installes la version 32-bit après la 64-bit, l'ancien binaire 64-bit est conservé.
Par ailleurs, je n'aime pas trop ce système de résolution implicite des conflits rpm à préférer par défaut les binaires 64-bit sans warning. Justement parce que c'est implicite, tu ne sais plus qu'il existait un conflit potentiel. C'est assez dangereux pour des générateurs car le code (source C par exemple) peut devoir être différent suivant que tu veux du 32-bit ou 64-bit. Heureusement, qu'on vérifie ce genre de choses. Le cas de glib2.0-devel a l'air sain i.e. ces 2 binaires sont censés être arch-indépendants (c'est pour générer du code faisant du marshaling).
Dans le cas où des binaires, ou bien des includes, ont un comportement différent suivant que tu veux du 32-bit ou 64-bit, Mandriva Linux a tout un dispositif pour différencier cela automatiquement (sauf pour le packager mais il existe des outils pour essayer de vérifier cela statiquement au build). De fait, tu as par exemple /usr/bin/multiarch-i386-linux/glib-config et /usr/bin/multiarch-x86_64-linux/glib-config. Tu vois clairement que différencier les 2 est important car --cflags doit fournir des résultats différents suivant que tu buildes du 32-bit ou 64-bit. Pareil pour les includes, e.g. #define QT_POINTER_SIZE 4 ou 8.
Au final, tu peux rebuilder des packages 32-bit aussi simplement que linux32 rpm --rebuild evolution.rpm (pour avoir du i586.rpm) ou rpm --rebuild evolution.rpm (pour avoir du x86_64.rpm).