Libllvm10 divergence de version entre i386 et amd64 sur testing (Debian 11 Bullseye)

Support Debian
#1

Mon pc est en multi-arch et la mise à jour laisse toujours un paquet non upgradé

Les paquets suivants ont été conservés :
  libllvm10:i386

Je vérifie le paquet

apt list --installed | grep libllvm10

libllvm10/testing,now 1:10.0.1-6 amd64  [installé]
libllvm10/now 1:10.0.1-6 i386 [installé, pouvant être mis à jour vers : 1:10.0.1-6+b1]

apt policy libllvm10:i386
libllvm10:i386:
  Installé : 1:10.0.1-6
  Candidat : 1:10.0.1-6+b1
 Table de version :
     1:10.0.1-6+b1 990
        990 https://cdn-aws.deb.debian.org/debian bullseye/main i386 Packages
        500 https://cdn-aws.deb.debian.org/debian sid/main i386 Packages
 *** 1:10.0.1-6 100
        100 /var/lib/dpkg/status

 apt policy libllvm10:amd64
libllvm10:
  Installé : 1:10.0.1-6
  Candidat : 1:10.0.1-6
 Table de version :
     1:10.0.1-6+b1 500
        500 https://cdn-aws.deb.debian.org/debian sid/main amd64 Packages
 *** 1:10.0.1-6 990
        990 https://cdn-aws.deb.debian.org/debian bullseye/main amd64 Packages
        100 /var/lib/dpkg/status

Le seul moyen de remettre cohérent:

sudo apt install libllvm10:amd64/sid libllvm10:i386/sid
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Version choisie « 1:10.0.1-6+b1 » (Debian:unstable [amd64]) pour « libllvm10 »
Version choisie « 1:10.0.1-6+b1 » (Debian:testing, Debian:unstable [i386]) pour « libllvm10:i386 »
Les paquets suivants seront mis à jour :
  libllvm10 libllvm10:i386
2 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 33,1 Mo dans les archives.
Après cette opération, 2 048 o d'espace disque supplémentaires seront utilisés.
Réception de :1 https://cdn-aws.deb.debian.org/debian bullseye/main i386 libllvm10 i386 1:10.0.1-6+b1 [16,5 MB]
Réception de :2 https://cdn-aws.deb.debian.org/debian sid/main amd64 libllvm10 amd64 1:10.0.1-6+b1 [16,6 MB]                       
33,1 Mo réceptionnés en 30s (1 104 ko/s)                                                                                           
(Lecture de la base de données... 240851 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de .../libllvm10_1%3a10.0.1-6+b1_i386.deb ...
Déconfiguration de libllvm10:amd64 (1:10.0.1-6) ...
Dépaquetage de libllvm10:i386 (1:10.0.1-6+b1) sur (1:10.0.1-6) ...
Préparation du dépaquetage de .../libllvm10_1%3a10.0.1-6+b1_amd64.deb ...
Dépaquetage de libllvm10:amd64 (1:10.0.1-6+b1) sur (1:10.0.1-6) ...
Paramétrage de libllvm10:amd64 (1:10.0.1-6+b1) ...
Paramétrage de libllvm10:i386 (1:10.0.1-6+b1) ...
Traitement des actions différées (« triggers ») pour libc-bin (2.31-4) ...

Pourquoi cette incohérence dans testing (Debian 11 Bullseye) ?

#2

‹ Testing › porte si bien son nom qu’on ne peut soupçonner aucune ambiguïté sur son objectif, la gestion du multi-arch étant bien certainement le dernier souci d’une « testing ».

Buster: libllvm7 - 1:7.0.1-8+deb10u2: amd64 i386

SID: libllvm10 - 1:10.0.1-6+b1: amd64 i386

Quand on a pas encore ce qu’on veut dans testing, on se sert dans SID.

#3

Testing c’est surtout la version anticipée de la prochaine stable, c’est pas un fourre-tout comme tu sembles le croire
Lire ci-dessous les explications
https://www.debian.org/releases/

Je penche plutôt sur le fait que le dev de libllvm10 n’a pas eu en tête l’incohérence et qu’il y pensera avant le passage en stable de Bullseye

#4

Si tu lis dans mes pensées, tu as donc fait une erreur de lecture, ou je me suis mal exprimé.

#5

Non, c’est ici le fonctionnement parfaitement normal de testing. Il s’écoule toujours un délai plus ou moins long entre la mise-à-jour d’un paquet en Sid et son arrivée au sein de testing.

Mais ça ne pose aucun souci, testing n’étant pas faite pour être utilisable en-dehors des périodes de freeze pour préparer la nouvelle stable. Si tu souhaites utiliser des versions de logiciels plus récentes que celles de la stable actuelle, c’est Sid la branche à utiliser :wink:

1 J'aime
#6

A préciser aussi que ‹ Testing › n’a absolument pas le même sens dans ses premiers balbutiements (après un passage testing -> stable), et 3 mois avant de passer en « stable ».
Ça fait bien longtemps que j’utilise la version testing/Bullseye, avec repo SID activé de temps en temps pour observer les différentiels de versions, et décider d’upgrader ou non un ensemble de paquets de versions identiques ( aptitude install ~U~Vxyzt ), mais il ne me serait jamais venu à l’idée de venir sur un forum pour exprimer mon étonnement d’une non-synchronisation de librairie amd64/i386 pour une testing.

A noter aussi qu’il est probable que Bullseye embarquera libllvm-11 avant de passer en stable.
Donc non, ‹ testing › ne veut pas dire ‹ fourre-tout ›: il faut juste comprendre son évolution de maturité au cours du temps, et donc sa gestion progressive de priorités dans le ‹ test ›, et admettre qu’on ne gère pas une testing (ou une SID), comme une stable.