Corriger les dépendances cassées sous Linux (APT et DNF)

sudo apt --fix-broken install répare la plupart des dépendances cassées sur Debian/Ubuntu, sudo dnf distro-sync réaligne les paquets sur RHEL/Fedora. Ces deux commandes sont le premier réflexe quand le gestionnaire de paquets refuse d'installer ou de mettre à jour quoi que ce soit.

Ce que vous allez apprendre

• Diagnostiquer le type de problème : installation interrompue, conflit ou paquet manquant
• Réparer une installation APT/dpkg interrompue
• Résoudre un conflit de dépendances avec APT et DNF
• Débloquer un gestionnaire de paquets verrouillé
• Connaître les commandes de dernier recours sans casser le système
• Prévenir les problèmes de dépendances

Dans quel contexte ?

Les dépendances cassées sont un problème classique en administration Linux :

• Une mise à jour a été interrompue (coupure réseau, Ctrl+C malencontreux, reboot pendant un apt upgrade), dpkg est dans un état incohérent
• Vous ajoutez un PPA ou un dépôt tiers qui fournit une version incompatible d'une bibliothèque partagée
• Un paquet a été supprimé manuellement avec dpkg --remove --force et d'autres paquets dépendent de lui
• Après une montée de version distribution, certains paquets ne sont plus disponibles dans les nouveaux dépôts
• apt install ou dnf install échoue avec un message de dépendances non satisfaites et vous ne savez pas par où commencer

LFCS / RHCSA

La gestion des paquets et la résolution de problèmes logiciels font partie du domaine Gestion logicielle de la RHCSA (dnf, modules AppStream) et du domaine Commandes essentielles de la LFCS. Savoir débloquer un gestionnaire de paquets cassé est une compétence attendue.

Diagnostiquer le problème

Une dépendance cassée n'est pas un état unique : le gestionnaire de paquets peut être bloqué par une transaction interrompue, par un paquet qui exige une version absente des dépôts, ou par une base de données locale qui ne reflète plus le contenu réel du disque. Les trois se corrigent différemment, et lancer la mauvaise commande en premier fait souvent perdre du temps.

Commencez donc par qualifier la panne. Les commandes ci-dessous ne modifient rien : elles se contentent de lire l'état local et sont sans risque même sur un serveur de production.

Debian / Ubuntu

Vérifier l'état de dpkg

sudo dpkg --audit

Si des paquets apparaissent, ils sont dans un état incohérent (installation partielle, configuration incomplète).

Vérifier les dépendances APT

sudo apt-get check

Reading package lists...
Building dependency tree...
Reading state information...

Si tout est propre, aucun message d'erreur n'apparaît. Sinon, APT indique les paquets avec des dépendances insatisfaites.

Lister les paquets cassés

dpkg --audit signale les paquets problématiques, mais sans montrer le code d'état exact qui explique pourquoi. Ce code se lit dans les deux premières colonnes de dpkg -l : la première décrit l'action souhaitée (i = à installer, r = à supprimer, h = gelé), la seconde l'état réel (i = installé, U = déballé, F = configuration à moitié faite, H = installation à moitié faite, c = seuls les fichiers de configuration restent).

La règle de lecture tient en une phrase : une majuscule dans la deuxième colonne est toujours un problème. Une troisième colonne R (Reinst-required) signale en plus un paquet qu'aucune commande ne pourra réparer sans réinstallation. Le filtre suivant isole ces cas :

dpkg -l | grep -E '^(iU|iF|iH|rc)'

Aucune sortie signifie qu'aucun paquet n'est en état incohérent. Les lignes rc sont bénignes : le paquet est supprimé, seuls ses fichiers de configuration subsistent.

État	Signification
ii	Installé correctement
iU	Déballé mais pas configuré
iF	Configuration échouée
iHR	Installation interrompue, nécessite réinstallation
rc	Supprimé, fichiers de config restants

Glissez pour voir

RHEL / Fedora

Vérifier la cohérence RPM

Contrairement à APT, DNF ne tient pas de fichier d'état séparé : tout vit dans la base RPM (/var/lib/rpm). La commande de contrôle interroge donc directement cette base et vous dit si ce qui est enregistré comme installé forme un ensemble cohérent.

sudo dnf check

Elle signale trois familles d'anomalies : les dépendances manquantes, les doublons (deux versions du même paquet installées en parallèle après une mise à jour partielle) et les conflits entre paquets. Sur un système sain, la commande ne renvoie rien et se termine avec un code de retour nul.

Lister les problèmes

dnf check répond par oui ou non. Pour savoir quel paquet précisément réclame une dépendance introuvable, il faut interroger le dépôt local avec repoquery.

sudo dnf repoquery --unsatisfied

Chaque ligne retournée correspond à un paquet installé dont une dépendance n'est plus fournie par aucun dépôt actif. C'est le symptôme typique d'un dépôt tiers désactivé ou d'une montée de version qui a retiré une bibliothèque.

Vérifier l'historique des transactions

DNF journalise chaque opération. Cet historique est le moyen le plus rapide de relier une panne à la dernière chose que vous avez faite, ce qui vaut mieux que de deviner.

sudo dnf history list

Regardez la colonne Action(s) : une transaction notée Install ou Upgrade juste avant l'apparition du problème est votre suspect principal. La colonne Altered donne le nombre de paquets touchés, un chiffre élevé indique une mise à jour de masse. Détaillez ensuite la transaction suspecte par son identifiant :

sudo dnf history info <id>

Réparer, Debian / Ubuntu

Les cinq étapes ci-dessous vont de la moins destructive à la plus intrusive : elles se suivent dans l'ordre, et vous vous arrêtez dès que dpkg --audit redevient silencieux. Sauter directement à la fin est le meilleur moyen de supprimer des paquets qui n'avaient besoin que d'être reconfigurés.

Un point de vigilance avant de commencer : lisez toujours le résumé que propose APT avant de valider. La commande --fix-broken a le droit de supprimer des paquets pour rétablir la cohérence, et sur un serveur en production, la liste des suppressions mérite un coup d'œil avant le Y.

1. Terminer les configurations dpkg en attente

   sudo dpkg --configure -a

   Cette commande termine la configuration de tous les paquets partiellement installés. C'est toujours la première chose à essayer.

2. Réparer les dépendances cassées avec APT

   sudo apt --fix-broken install

   APT télécharge et installe les dépendances manquantes, ou supprime les paquets incohérents. Vérifiez ce qu'il propose avant de confirmer.

3. Mettre à jour la liste des paquets

   sudo apt update

   Si un dépôt a été modifié ou supprimé, les métadonnées locales sont peut-être obsolètes.

4. Réessayer l'installation

   sudo apt install -f

   L'option -f (fix) force APT à résoudre les dépendances avant de continuer.

5. Vérifier le résultat

   sudo dpkg --audit
   sudo apt-get check

   Les deux commandes doivent être silencieuses (aucune sortie = système propre).

Cas spécial : dpkg verrouillé

Si apt ou dpkg affiche :

E: Could not get lock /var/lib/dpkg/lock-frontend

Un autre processus dpkg est en cours. Vérifiez d'abord :

ps aux | grep -E 'apt|dpkg'

Si un processus apt ou dpkg tourne encore, attendez qu'il finisse. Si la machine a redémarré pendant une mise à jour et qu'aucun processus ne tourne :

sudo rm /var/lib/dpkg/lock-frontend
sudo rm /var/lib/dpkg/lock
sudo dpkg --configure -a

Ne supprimez les verrous que si aucun processus dpkg ne tourne

Supprimer un fichier lock pendant qu'un apt est actif peut corrompre la base de données dpkg. Vérifiez toujours avec ps aux | grep dpkg avant.

Cas spécial : paquet impossible à supprimer

Quand un paquet porte le drapeau R (Reinst-required), dpkg refuse de le manipuler : il considère que son contenu sur disque n'est plus fiable et exige une réinstallation. Si le paquet n'existe plus dans aucun dépôt, vous êtes bloqué en boucle. L'option --force-remove-reinstreq lève précisément ce garde-fou.

sudo dpkg --remove --force-remove-reinstreq nom-du-paquet
sudo apt --fix-broken install

La deuxième commande n'est pas optionnelle : la suppression forcée laisse les paquets qui dépendaient de la victime dans un état insatisfait, et c'est --fix-broken qui rétablit l'ensemble. Vérifiez la liste des options disponibles avec dpkg --force-help avant d'en employer une autre : les entrées marquées [!] sont considérées comme dangereuses par dpkg lui-même.

Forcer la réinstallation d'un paquet

Certaines pannes ne viennent pas des dépendances mais des fichiers livrés par le paquet : un binaire écrasé à la main, une configuration supprimée par erreur, un fichier tronqué par un disque plein. Dans ce cas, la réinstallation remet le contenu d'origine en place sans toucher aux dépendances.

sudo apt install --reinstall nom-du-paquet

Le paquet est retéléchargé puis réinstallé par-dessus l'existant, sans passer par une suppression : les paquets qui dépendent de lui ne sont donc jamais désinstallés au passage. Les fichiers de configuration modifiés dans /etc sont conservés, APT vous demande quoi faire s'ils diffèrent de la version du mainteneur.

Réparer, RHEL / Fedora

La logique diffère de celle d'APT. DNF ne connaît pas d'état « à moitié configuré » : une transaction RPM est atomique, elle passe ou elle échoue. Les pannes viennent donc rarement d'une interruption, et bien plus souvent d'un écart entre les versions installées et celles publiées par les dépôts actifs. C'est ce que corrige distro-sync, en réalignant chaque paquet, y compris en le rétrogradant si le dépôt propose une version inférieure.

Comme côté Debian, suivez les étapes dans l'ordre et vérifiez avec dnf check après chacune : inutile de reconstruire la base RPM si une simple resynchronisation a suffi.

1. Synchroniser les paquets avec les dépôts

   sudo dnf distro-sync

   Aligne tous les paquets installés sur les versions disponibles dans les dépôts actifs. Résout la plupart des problèmes post-mise à jour.

2. Réinstaller un paquet suspect

   sudo dnf reinstall nom-du-paquet

3. Vérifier et réparer la base RPM

   sudo rpm --rebuilddb

   Reconstruit la base de données RPM si dnf signale des erreurs d'accès à la base.

4. Nettoyer le cache

   sudo dnf clean all
   sudo dnf makecache

   Force le retéléchargement des métadonnées de tous les dépôts.

5. Vérifier le résultat

   sudo dnf check

Annuler une transaction DNF

C'est l'avantage décisif de DNF sur APT : chaque transaction est enregistrée avec la liste exacte des paquets touchés et leurs versions précédentes, ce qui rend le retour en arrière possible en une commande. Commencez par retrouver l'identifiant de la transaction fautive.

sudo dnf history list

ID | Command line             | Date and time    | Action(s) | Altered
 8 | install nginx            | 2026-04-15 14:30 | Install   | 3
 7 | update                   | 2026-04-14 09:00 | Upgrade   | 42

Pour annuler la transaction n°8 :

sudo dnf history undo 8

DNF défait les changements effectués par cette transaction (supprime les paquets installés, restaure les versions précédentes). L'annulation n'aboutit que si les anciennes versions sont encore disponibles dans un dépôt ou dans le cache local : sur une machine où dnf clean all a été passé après la mise à jour, l'opération peut échouer faute de RPM à réinstaller.

Résoudre un conflit de version

Un dépôt tiers qui publie sa propre version d'une bibliothèque système (souvent une variante plus récente de glibc, d'openssl ou d'un module Python) prend le pas sur celle de la distribution. Les paquets officiels compilés contre la version d'origine se retrouvent alors avec une dépendance insatisfaite. Trois commandes suffisent à identifier le coupable puis à le neutraliser.

# Identifier le dépôt source
dnf repoquery --info nom-du-paquet

# Exclure un dépôt temporairement
sudo dnf update --disablerepo=nom-du-depot-tiers

# Verrouiller un paquet à sa version actuelle
sudo dnf versionlock add nom-du-paquet

--disablerepo ne vaut que pour la commande en cours, c'est un test sans effet durable. versionlock en revanche est persistant : le paquet gelé ne bougera plus, y compris lors des mises à jour de sécurité. Notez-le quelque part, un verrou oublié se transforme en dette six mois plus tard. La sous-commande versionlock réclame un plugin séparé, dont l'installation est détaillée avec le blocage de paquets.

Problèmes liés aux dépôts tiers

Identifier les dépôts problématiques

Un conflit de dépendances vient très souvent d'un dépôt ajouté à la main : PPA Ubuntu, dépôt d'éditeur, EPEL sur RHEL. Le premier réflexe consiste donc à faire l'inventaire de ce qui est réellement activé sur la machine, ce qui prend une commande par famille de distribution.

# Debian/Ubuntu
grep -r "^deb " /etc/apt/sources.list /etc/apt/sources.list.d/

# RHEL/Fedora
dnf repolist

Sur Debian et Ubuntu, tout ce qui ne pointe pas vers deb.debian.org, archive.ubuntu.com ou votre miroir interne est un candidat. Sur RHEL, comparez la colonne repo id avec la liste des dépôts fournis par l'abonnement : les identifiants qui n'y figurent pas ont été ajoutés localement.

Format deb822 depuis Ubuntu 24.04

Sur Ubuntu 24.04, /etc/apt/sources.list ne contient plus qu'un commentaire : les dépôts officiels vivent dans /etc/apt/sources.list.d/ubuntu.sources, au format deb822 (Types:, URIs:, Suites:). Les lignes ne commencent plus par deb, donc le grep ci-dessus les rate. Inspectez aussi /etc/apt/sources.list.d/*.sources, ou utilisez apt policy qui affiche toutes les sources quel que soit leur format.

Désactiver temporairement un dépôt

Isoler un dépôt suspect est un test de diagnostic, pas une correction. L'objectif est de répondre à une seule question : le problème disparaît-il quand ce dépôt n'est plus consulté ? Les manipulations ci-dessous sont réversibles, ce qui les rend sûres même sur un serveur en service.

Debian / Ubuntu

# Renommer le fichier pour le désactiver
sudo mv /etc/apt/sources.list.d/depot-tiers.list /etc/apt/sources.list.d/depot-tiers.list.disabled
sudo apt update
sudo apt --fix-broken install

RHEL / Fedora

sudo dnf --disablerepo=depot-tiers update
# Ou désactivation permanente
sudo dnf config-manager --set-disabled depot-tiers

config-manager provient du paquet dnf-plugins-core. Sur les distributions passées à DNF 5 (Fedora 41 et suivantes), la syntaxe devient dnf config-manager setopt depot-tiers.enabled=0.

Vérifier les paquets provenant de dépôts tiers (APT)

Désactiver un dépôt ne suffit pas toujours : les paquets qu'il a déjà installés restent en place, avec leurs versions non standard. Le filtre ci-dessous les fait remonter en éliminant les paquets dont la version contient ubuntu ou debian, marqueur habituel d'un paquet issu des dépôts officiels.

apt list --installed 2>/dev/null | grep -v "ubuntu\|debian"

C'est une heuristique, pas une vérité : beaucoup de paquets officiels ne portent pas ce marqueur dans leur version et apparaîtront à tort. Pour trancher sur un paquet précis, apt policy nom-du-paquet affiche le dépôt d'origine exact de la version installée.

Bloquer un paquet pour éviter les mises à jour

Quand une version plus récente casse systématiquement l'installation, geler le paquet à sa version connue comme fonctionnelle vous laisse le temps de traiter le fond du problème. Les deux familles de distributions ont chacune leur mécanisme, avec la même logique : bloquer, vérifier, débloquer.

Debian / Ubuntu

# Bloquer
sudo apt-mark hold nom-du-paquet

# Vérifier
apt-mark showhold

# Débloquer
sudo apt-mark unhold nom-du-paquet

RHEL / Fedora

# Installer le plugin versionlock
sudo dnf install dnf-plugin-versionlock

# Bloquer
sudo dnf versionlock add nom-du-paquet

# Lister
dnf versionlock list

# Débloquer
sudo dnf versionlock delete nom-du-paquet

Prévenir les problèmes

La quasi-totalité des dépendances cassées vient de trois gestes : une interruption de transaction, l'ajout d'un dépôt tiers non maîtrisé, et une mise à jour lancée sans essai préalable. Les réflexes ci-dessous coûtent quelques secondes et évitent les heures de réparation décrites plus haut.

• Ne jamais interrompre apt upgrade ou dnf update, si un Ctrl+C est nécessaire, exécutez dpkg --configure -a ou dnf distro-sync immédiatement après
• Éviter les dépôts tiers non fiables, chaque PPA ou dépôt externe est un risque de conflit
• Tester les mises à jour majeures sur un serveur de test avant la production (apt upgrade --dry-run, dnf update --assumeno)
• Garder les métadonnées à jour : apt update avant chaque installation
• Documenter les paquets bloqués (apt-mark showhold, dnf versionlock list), un paquet gelé oublié deviendra un problème plus tard

Dépannage

Ce tableau relie chaque message d'erreur brut rencontré dans un terminal à la commande qui le corrige. Cherchez d'abord la ligne dont le symptôme correspond mot pour mot à ce que vous lisez : les gestionnaires de paquets ont un vocabulaire d'erreur restreint, et le message est presque toujours suffisant pour trancher sans diagnostic supplémentaire.

Symptôme	Cause probable	Solution
Could not get lock /var/lib/dpkg/lock	Autre processus dpkg actif	Vérifier ps aux | grep dpkg, attendre ou supprimer le lock si aucun processus
Unmet dependencies après install	Dépôt tiers incompatible	Désactiver le dépôt, apt --fix-broken install
dpkg --configure -a boucle en erreur	Script postinst du paquet cassé	dpkg --remove --force-remove-reinstreq paquet
dnf check signale des doublons	Mise à jour partielle	dnf remove --duplicates puis dnf distro-sync
Package X has no installation candidate	Dépôt supprimé ou paquet retiré	apt update, vérifier les sources
Error: Transaction check error (DNF)	Conflit entre packages	dnf --best --allowerasing install paquet
Base RPM corrompue	Crash pendant transaction	rpm --rebuilddb puis dnf clean all

Glissez pour voir

Gardez ce bloc sous la main : ce sont les commandes de lecture seule à passer en premier sur une machine dont vous ne connaissez pas l'historique. Aucune ne modifie quoi que ce soit, elles servent uniquement à décider quelle réparation lancer ensuite.

# Diagnostic rapide : Debian/Ubuntu
sudo dpkg --audit                    # Paquets en état incohérent
sudo apt-get check                   # Dépendances insatisfaites
apt-mark showhold                    # Paquets bloqués

# Diagnostic rapide : RHEL/Fedora
sudo dnf check                       # Cohérence des dépendances
sudo dnf history list                # Dernières transactions
dnf versionlock list                 # Paquets verrouillés

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• dpkg --configure -a est toujours la première commande après une installation interrompue sur Debian/Ubuntu
• apt --fix-broken install résout la majorité des problèmes de dépendances APT
• dnf distro-sync réaligne tous les paquets sur RHEL/Fedora, c'est l'équivalent du « fix broken » côté DNF
• Ne supprimez jamais les fichiers lock si un processus dpkg/apt est encore actif
• dnf history undo permet d'annuler une transaction problématique, APT n'a pas d'équivalent aussi simple
• Les dépôts tiers sont la première cause de conflits de dépendances, désactivez-les pour isoler le problème
• apt-mark hold et dnf versionlock bloquent un paquet pour éviter des mises à jour incompatibles
• En dernier recours, dpkg --remove --force-remove-reinstreq permet de supprimer un paquet irrécupérable

×

📖 Voir la documentation →