Échec de apt update/upgrade après un changement de version de Debian : résoudre manuellement les conflits de paquets

Il y a quelque temps, l’un de mes serveurs d’expérimentation s’est retrouvé exactement à ce point : j’ai dû résoudre manuellement des conflits de paquets apt « à la main ». J’avais un système Debian qui n’avait jamais été complètement mis à jour pendant des années, mais qui était resté coincé quelque part entre Stretch et Bookworm – avec un mélange sauvage de versions de paquets qui ne devraient en réalité jamais coexister sur la même machine. apt refusait de faire quoi que ce soit et dpkg --configure -a échouait sans cesse au même endroit. À la fin, aucune commande standard n’aidait plus. J’ai dû décompresser manuellement les paquets .deb avec Python, juste pour comprendre ce que le gestionnaire de paquets voulait installer et quels fichiers étaient déjà présents sur le système, et dans quelle version.

C’est précisément ce scénario – un changement de version (release upgrade) qui n’a pas été mené jusqu’au bout, et qui se venge des mois ou des années plus tard sous forme d’erreurs apt cryptiques – qui est le cas classique abordé dans cet article.

Tu as modifié le fichier /etc/apt/sources.list de stretch vers bullseye ou de bullseye vers bookworm, apt update passe encore – mais au moment de apt upgrade ou apt full-upgrade, tout s’arrête en produisant des messages d’erreur cryptiques. Ce problème est bien plus fréquent qu’on ne le pense, surtout sur des serveurs qui tournent depuis longtemps et qui « ont traversé » plusieurs générations de Debian, au lieu d’être remis à neuf à chaque fois.

Pourquoi cela arrive

Un changement de version Debian n’est pas juste un simple passage à une version supérieure. Entre deux générations de Debian, plusieurs choses changent :

• Noms et découpages de paquets – un paquet est divisé en deux, ou deux paquets sont fusionnés
• Versions des dépendances – un paquet exige maintenant une version de libc qui n’est pas encore installée
• Formats des fichiers de configuration – dpkg demande lors d’un upgrade si un fichier de conf modifié doit être écrasé, et s’interrompt lors des exécutions non-interactives (ex : via SSH avec -y) exactement à cette étape
• Résidus d’anciens dépôts – si le fichier sources.list contient encore des lignes de l’ancienne version (erreur typique : seule la ligne principale a été modifiée mais -updates ou -security oubliés), apt mélange alors des paquets de deux générations

Ainsi, on aboutit généralement à l’une de ces trois catégories d’erreurs :

1. trying to overwrite '/usr/lib/xyz', which is also in package abc
2. The following packages have unmet dependencies
3. dpkg: error processing package xyz (--configure): dependency problems - leaving unconfigured

Étape 1 : État des lieux au lieu de paniquer

Avant d’installer ou de supprimer quoi que ce soit, commence par faire un état des lieux propre :

apt list --upgradable 2>/dev/null
apt-cache policy | head -20
cat /etc/apt/sources.list /etc/apt/sources.list.d/*.list

Vérifie ici précisément si toutes les lignes (main, updates, security, éventuellement backports) pointent vers la même version. C’est la cause la plus fréquente et cela se corrige en 5 minutes – avant de partir dans la chasse à des bugs plus complexes qui ne sont souvent que des symptômes de cette seule erreur.

Étape 2 : Mettre dpkg dans un état propre

Si dpkg s’arrête au milieu d’une configuration, commence par :

sudo dpkg --configure -a

Cela essaie de finir la configuration de tous les paquets à moitié installés. Si une erreur survient sur un paquet particulier, note son nom – ce sera ton point d’entrée pour le dépannage ciblé.

Étape 3 : Laisser apt réparer les dépendances automatiquement

sudo apt --fix-broken install

C’est la commande qui règle la majorité des cas : apt cherche tout seul une combinaison d’installations/suppressions qui rende la chaîne de dépendances à nouveau cohérente. Important : lis la liste des changements proposés avant de confirmer – il arrive qu’apt propose de supprimer un paquet dont tu as besoin, parce qu’il ne trouve (pas encore) de version compatible.

Étape 4 : Le cas « trying to overwrite »

Ce message d’erreur signifie : deux paquets veulent installer le même fichier, car la structure des paquets a changé entre les versions (par exemple, un paquet a été scindé en paket-common et paket-bin). La solution rapide mais risquée serait dpkg -i --force-overwrite. Ne fais pas ça en premier. Commence plutôt par vérifier s’il s’agit d’un problème de split connu :

dpkg -S /chemin/vers/le/fichier_conflit
apt-cache policy <paquet-concerné>

En général, il suffit de supprimer proprement l’ancien paquet devenu superflu (apt remove <ancien-paquet>) au lieu d’installer le nouveau en force par-dessus. Les installations forcées laissent souvent des bases de données dpkg incohérentes qui risquent de te causer à nouveau des soucis plusieurs semaines plus tard.

Étape 5 : Si plus rien ne fonctionne – analyse manuelle des .deb

Dans les cas récalcitrants où apt/dpkg se bloquent mutuellement (par exemple en présence d’un mélange de deux versions intermédiaires non supportées), il peut être utile d’extraire et inspecter manuellement le paquet concerné, plutôt que de continuer à faire confiance au gestionnaire de paquets :

apt-get download <nom-du-paquet>
dpkg-deb -R <nom-du-paquet>*.deb /tmp/contenu-paquet

Tu vois ainsi exactement quels fichiers le paquet veut installer et tu peux comparer manuellement ce qui est déjà présent sur le système (éventuellement sous un autre nom). C’est la solution de dernier recours quand la méthode classique via apt --fix-broken install aboutit à une impasse – par exemple si la base de données de paquets est tellement corrompue (mix de deux ou trois générations Debian) qu’apt ne parvient plus à calculer un chemin de mise à jour valide.

Prévention pour la prochaine fois

• Toujours effectuer un changement de version via do-release-upgrade (sur Ubuntu) ou via le guide officiel de mise à niveau Debian, et non pas en modifiant le fichier sources.list à la main suivi d’un dist-upgrade
• Faire un snapshot ou une sauvegarde du système avant chaque upgrade (snapshot LVM, snapshot de VM, ou au moins dpkg --get-selections > pakete-backup.txt)
• Réécrire sources.list entièrement à chaque changement plutôt qu’éditer ligne par ligne – cela évite d’oublier une ligne -security

Conclusion

La plupart des cas de « apt cassé après un changement de version » ne sont pas des dommages systèmes sérieux, mais des états intermédiaires incohérents, qu’on peut résoudre proprement dans plus de 80 % des cas avec dpkg --configure -a suivi de apt --fix-broken install. Seuls les cas vraiment tenaces justifient une analyse manuelle des .deb – mais tu contrôles alors pleinement ce qui se passe sur le système, au lieu de « jouer aux dés » avec --force-overwrite.

Dans mon cas d’époque avec le serveur mail, c’était finalement la seule façon de retrouver un système fonctionnel : extraire chaque paquet manuellement, comparer, décider ce qu’on garde et ce qu’on enlève – au lieu de faire confiance aveuglément au gestionnaire de paquets, qui dans cet état intermédiaire corrompu était tout simplement incapable de trouver un chemin de mise à jour. La leçon a été moins technique qu’organisationnelle : un changement de version fait à la va-vite « entre deux choses » finit presque toujours par se venger, parfois après plusieurs mois – mais alors, sérieusement.