Dépannage d'APT sous Ubuntu : Corriger les paquets cassés, les retenues et les erreurs GPG

Les échecs d’APT sont courants sur les machines Ubuntu de longue durée, et ils apparaissent généralement après une mise à niveau de version, un changement de dépôt tiers, la suppression d’un PPA, l’installation manuelle d’un fichier .deb ou une installation de paquets interrompue.

Le message d’erreur peut sembler dramatique, mais la plupart des problèmes d’APT ne sont pas mystérieux — ce sont des problèmes d’état où la vision d’APT concernant les dépôts, les versions et les paquets installés n’est plus cohérente.

APT essaie de répondre à quatre questions :

1. Quels dépôts sont activés ?
2. Quelles versions de paquets sont disponibles ?
3. Quels paquets sont déjà installés ?
4. Quels changements de paquets sont autorisés ?

Lorsque ces réponses entrent en conflit, vous obtenez des paquets maintenus (held), des dépendances brisées, des clés publiques manquantes, des erreurs de PPA ou des paquets retenus (kept back) lors de la mise à niveau. Ce guide vous donne une séquence pratique de dépannage pour APT sous Ubuntu, écrite pour les développeurs, les ingénieurs DevOps et les utilisateurs Linux qui souhaitent réparer le système sans copier aveuglément des commandes aléatoires issues de fils de discussion de forums. Associez-le à notre cheat sheet Ubuntu APT et dpkg pour les commandes quotidiennes d’installation et de mise à niveau, et parcourez la collection plus large des Outils Développeur pour des workflows Linux connexes.

La version courte

Si votre système n’est que légèrement endommagé, commencez ici :

sudo apt update
sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt update
sudo apt upgrade

Si des paquets sont retenus (kept back) :

apt list --upgradable
apt-mark showhold
sudo apt full-upgrade

Si un PPA ou un dépôt tiers échoue :

ls /etc/apt/sources.list.d/
sudo apt update

Lisez la ligne du dépôt qui échoue, puis désactivez ou réparez ce dépôt. Si vous voyez NO_PUBKEY, n’importez pas aveuglément des clés aléatoires depuis un serveur de clés — trouvez les instructions officielles du dépôt, installez la clé du dépôt dans /etc/apt/keyrings et liez-la à ce dépôt avec signed-by.

Avant de réparer quoi que ce soit : lisez l’erreur APT

Exécutez ceci en premier :

sudo apt update

Ne le passez pas. apt update actualise les métadonnées des paquets. Il ne met pas à niveau les paquets. Il vous indique si Ubuntu peut lire tous les dépôts configurés et vérifier leurs métadonnées.

Vérifiez ensuite votre version Ubuntu et son nom de code — un nom de version obsolète dans /etc/apt/sources.list.d/ est une cause fréquente d’erreurs 404 et de fichiers Release. Si vous n’êtes pas sûr de la version que vous utilisez, consultez comment vérifier votre version Ubuntu :

lsb_release -a

Ou :

cat /etc/os-release

Vérifiez également ce qui est mis à niveau :

apt list --upgradable

Et vérifiez si un paquet est maintenu (held) :

apt-mark showhold

Cela vous donne la première division dans l’arbre de décision — identifier la classe d’échec en premier facilite le dépannage car chaque classe a une première réparation différente :

• Problème de dépôt : apt update échoue.
• Problème de dépendance : apt update fonctionne, mais l’installation ou la mise à niveau échoue.
• Problème de paquet maintenu (held) : APT refuse de modifier des paquets spécifiques.
• Problème de source mixte : un PPA, un .deb manuel ou un ancien dépôt fournit des versions incompatibles.
• Problème d’installation interrompue : dpkg a décompressé des paquets qui n’ont jamais été configurés.

Types courants d’échec d’APT sous Ubuntu

Paquets retenus (Kept Back)

Un paquet retenu (kept back) n’est pas toujours une erreur ; cela signifie qu’APT a choisi de ne pas mettre à niveau un paquet en utilisant la commande actuelle. Cela arrive souvent lorsque la mise à niveau nécessite l’installation de nouvelles dépendances, la suppression de paquets anciens ou la modification d’un paquet d’une manière que apt upgrade simple ne peut pas effectuer.

Vérifiez les détails :

apt list --upgradable
apt-cache policy package-name

Essayez une mise à niveau complète uniquement après avoir lu ce qu’APT souhaite faire :

sudo apt full-upgrade

full-upgrade est autorisé à installer de nouveaux paquets et à supprimer des paquets si nécessaire pour terminer la mise à niveau. C’est utile, mais c’est aussi pourquoi vous devriez lire les changements proposés avant d’accepter. Sur une station de travail, full-upgrade est généralement acceptable après examen ; sur un serveur, lisez les suppressions deux fois.

Paquets maintenus (Held Packages)

Un paquet maintenu (held) est différent d’un paquet qui est simplement retenu (kept back). Un maintien (hold) est une instruction explicite qui empêche APT d’installer, de mettre à niveau ou de supprimer automatiquement ce paquet. Les maintenues sont utiles pour fixer une version de noyau, de base de données, de pilote ou d’environnement d’exécution, et ils sont aussi faciles à oublier.

Liste des paquets maintenus :

apt-mark showhold

Maintenir un paquet :

sudo apt-mark hold package-name

Retirer un maintien :

sudo apt-mark unhold package-name

Si vous voyez des erreurs de dépendance impliquant un paquet maintenu, décidez si le maintien est toujours intentionnel. Ne retirez pas les maintenues automatiquement. Ils peuvent protéger un service de production, un pilote ou une chaîne d’outils sensible à la compatibilité.

Dépendances brisées

Des dépendances brisées signifient qu’APT ne peut pas trouver un ensemble de paquets valide, ce qui pointe généralement vers un conflit de version plutôt qu’un téléchargement corrompu.

Les causes courantes incluent :

• Un paquet nécessite une version qui n’est pas disponible.
• Un PPA fournit une bibliothèque plus récente que ce qu’Ubuntu attend.
• Un .deb installé manuellement dépend de paquets d’une autre version.
• Une installation de paquet a été interrompue.
• Un dépôt pour la mauvaise version d’Ubuntu est activé.
• Le verrouillage (pinning) ou les maintenues de paquets empêchent le changement de version nécessaire.

Commencez par :

sudo dpkg --configure -a
sudo apt --fix-broken install

Inspectez ensuite le paquet :

apt-cache policy package-name
apt-cache depends package-name
apt-cache rdepends package-name

Utilisez ensuite ces commandes pour trouver le conflit de version de paquet qui bloque APT, plutôt que d’exécuter chaque commande de réparation en séquence.

Erreurs de clé GPG et NO_PUBKEY

Une erreur NO_PUBKEY signifie qu’APT a reçu les métadonnées du dépôt, mais qu’il ne peut pas vérifier la signature car la clé publique requise est manquante — un problème de confiance, et non simplement un problème de téléchargement.

Une erreur typique ressemble à ceci :

Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY ABCD1234EF567890

Les anciennes instructions utilisaient souvent apt-key add, mais évitez cela pour la configuration des nouveaux dépôts. Les systèmes Ubuntu modernes doivent utiliser un trousseau de clés (keyring) spécifique au dépôt et signed-by.

Un meilleur modèle ressemble à ceci :

sudo install -d -m 0755 /etc/apt/keyrings

curl -fsSL https://example.com/repo-key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/example.list

sudo apt update

Remplacez l’URL et la ligne du dépôt par les instructions officielles du fournisseur.

La partie importante est celle-ci :

signed-by=/etc/apt/keyrings/example.gpg

Cette ligne signed-by lie la clé à un seul dépôt, ce qui est plus propre et plus sûr que de placer chaque clé tierce dans un magasin de confiance global.

Erreurs de PPA ou de fichier Release

Les échecs de PPA ressemblent souvent à ceci :

Le dépôt n'a pas de fichier Release.

Ou :

404 Not Found

Causes courantes :

• Le PPA ne prend pas en charge votre version d’Ubuntu.
• Vous avez mis à niveau Ubuntu, mais le PPA pointe toujours vers l’ancien nom de code.
• Le PPA a été supprimé.
• Le mainteneur a cessé de publier des paquets.
• Vous avez ajouté un PPA destiné à une autre version d’Ubuntu.

Vérifiez votre nom de code :

. /etc/os-release
echo "$VERSION_CODENAME"

Listez les fichiers de source tiers :

ls /etc/apt/sources.list.d/

Inspectez-les :

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

Désactivez une source suspecte en la renommant :

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Si APT fonctionne après avoir désactivé le fichier, vous avez trouvé la source problématique et pouvez la réparer ou la supprimer définitivement.

Un workflow de dépannage APT sûr

Étape 1 : Actualiser les métadonnées

sudo apt update

Si cela échoue, réparez les dépôts avant d’essayer de réparer les paquets. APT ne peut pas résoudre les dépendances correctement si son index de paquets est obsolète ou incomplet.

Recherchez des lignes contenant :

NO_PUBKEY
Release file
404 Not Found
does not have a Release file
The repository is not signed

Ce sont des problèmes de dépôt ou de confiance, et ils doivent être corrigés avant que vous ne tentiez toute réparation de paquets.

Étape 2 : Terminer la configuration des paquets interrompue

Si une installation de paquet a été interrompue, dpkg peut avoir décompressé des fichiers mais pas configuré le paquet.

Exécutez :

sudo dpkg --configure -a

Si cela réussit, continuez :

sudo apt --fix-broken install

Si cela échoue, lisez attentivement le nom du paquet et l’erreur. Le paquet nommé en bas de l’erreur est souvent plus important que le paquet que vous essayiez d’installer initialement.

Étape 3 : Demander à APT de réparer les dépendances

sudo apt --fix-broken install

Cette commande demande à APT de corriger les problèmes de dépendance en installant les dépendances manquantes ou en supprimant les paquets qui ne peuvent pas être satisfaits. Lisez attentivement l’action proposée, en particulier les suppressions.

Soyez prudent si APT veut supprimer :

• ubuntu-desktop
• ubuntu-server
• linux-generic
• les paquets du gestionnaire d’affichage
• les paquets réseau
• les paquets de base de données
• les paquets d’environnement d’exécution de conteneurs
• les paquets de l’environnement de bureau

Parfois, la suppression d’un métapaquet est inoffensive. Parfois, c’est un signe avant-coureur que vos sources de paquets sont mal mélangées. N’acceptez pas de grandes suppressions sans les comprendre.

Étape 4 : Vérifier les paquets maintenus (Held)

apt-mark showhold

Si un paquet maintenu bloque la mise à niveau, inspectez-le :

apt-cache policy package-name

Si le maintien n’est plus nécessaire :

sudo apt-mark unhold package-name
sudo apt update
sudo apt upgrade

Si le maintien est intentionnel, ne luttez pas contre APT — réparez le dépôt ou la sélection de paquets autour du maintien au lieu de supprimer la protection.

Étape 5 : Inspecter les versions des paquets

Pour un paquet ayant des problèmes de dépendance :

apt-cache policy package-name

Cela montre :

• Version installée
• Version candidate
• Versions disponibles
• Quel dépôt fournit chaque version

apt-cache policy est l’une des commandes de débogage APT les plus utiles car elle montre d’où provient chaque version disponible.

Exemple :

apt-cache policy docker-ce

Si la version candidate provient d’un PPA inattendu ou d’un ancien dépôt, vous avez trouvé la cause probable du conflit de dépendance.

Étape 6 : Rechercher des dépôts mélangés

Listez les sources activées :

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

Recherchez :

• Anciens noms de code Ubuntu
• Dépôts Debian sur Ubuntu
• PPAs pour une autre version d’Ubuntu
• Dépôts de fournisseurs en double
• Instructions Snap et APT mélangées pour le même outil
• Anciens fichiers .list laissés derrière après la désinstallation de logiciels

Un anti-motif courant est d’installer un outil depuis un dépôt de fournisseur, puis d’ajouter plus tard un PPA ou un .deb manuel qui fournit des bibliothèques chevauchantes. APT peut gérer de nombreuses sources, mais il ne peut pas réconcilier des intentions conflictuelles sauf si vous alignez vous-même les dépôts.

Étape 7 : Essayer une installation ou une mise à niveau simulée

Avant d’apporter des modifications, simulez :

apt -s install package-name

Ou :

apt -s full-upgrade

L’option -s simule l’opération. Elle est utile lorsque vous voulez voir ce qu’APT ferait sans modifier le système.

Réparer les paquets maintenus (Held)

Lister les paquets maintenus

apt-mark showhold

Si rien n’est affiché, aucun paquet n’est maintenu avec apt-mark, et vous pouvez passer aux vérifications de dépendance ou de dépôt.

Maintenir un paquet intentionnellement

sudo apt-mark hold package-name

Bonnes raisons de maintenir un paquet :

• Une version du noyau est connue pour fonctionner avec votre matériel.
• Une mise à niveau de base de données nécessite une planification.
• Une mise à jour du pilote brise votre GPU.
• Une version d’exécution doit correspondre à la production.
• Un paquet de fournisseur n’est pas compatible avec la dernière dépendance.

Mauvaises raisons de maintenir un paquet :

• Vous avez copié une commande depuis un ancien guide.
• Vous avez oublié pourquoi il était maintenu.
• Vous évitez une erreur de dépendance sans la comprendre.

Retirer un maintien

sudo apt-mark unhold package-name

Ensuite, mettez à jour et mettez à niveau :

sudo apt update
sudo apt upgrade

Si le paquet ne se met toujours pas à niveau, ce n’était pas seulement un problème de maintien. Vérifiez la politique :

apt-cache policy package-name

Réparer les dépendances brisées

La séquence de réparation standard

Utilisez cette séquence lorsque l’installation ou la mise à niveau d’un paquet a échoué en cours de route :

sudo apt update
sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt upgrade

Cet ordre est important car chaque étape prépare le terrain pour la suivante : apt update actualise les métadonnées du dépôt, dpkg --configure -a termine la configuration des paquets décompressés, apt --fix-broken install permet à APT de réconcilier les dépendances manquantes ou conflictuelles, et apt upgrade reprend les mises à niveau normales des paquets.

Supprimer un paquet local mal installé

Si le problème a commencé après l’installation d’un .deb téléchargé, inspectez-le :

dpkg -l | grep package-name
apt-cache policy package-name

Supprimez-le :

sudo apt remove package-name

Si les fichiers de configuration causent également des problèmes :

sudo apt purge package-name

Ensuite, réparez :

sudo apt --fix-broken install

Réinstaller un paquet endommagé

Si un paquet est installé mais brisé :

sudo apt install --reinstall package-name

Cela est utile lorsque des fichiers sont manquants ou corrompus, mais que les sources des paquets sont par ailleurs saines et que vous souhaitez rafraîchir les fichiers installés sans changer de version.

Réparer les problèmes de PPA et de dépôts tiers

Trouver les PPAs et dépôts tiers

ls /etc/apt/sources.list.d/

Afficher les lignes de dépôt actives :

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

Sur les systèmes Ubuntu plus récents, vous pouvez également voir des fichiers .sources utilisant le format deb822 :

ls /etc/apt/sources.list.d/*.sources

Affichez-les :

cat /etc/apt/sources.list.d/*.sources

Désactiver un PPA en toute sécurité

Renommez le fichier source :

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Pour les fichiers deb822 :

sudo mv /etc/apt/sources.list.d/example.sources /etc/apt/sources.list.d/example.sources.disabled
sudo apt update

Le renommage du fichier source est réversible et plus sûr que la suppression immédiate de la configuration du dépôt, car vous pouvez le renommer à nouveau si vous avez désactivé la mauvaise source.

Supprimer les paquets d’un PPA

La désactivation d’un PPA arrête les futurs téléchargements de paquets depuis celui-ci. Elle ne rétrograde pas automatiquement les paquets déjà installés depuis ce PPA.

Si le PPA a causé des conflits de bibliothèque, vous devrez peut-être rétrograder les paquets aux versions Ubuntu.

Installez ppa-purge :

sudo apt install ppa-purge

Ensuite, purgez le PPA :

sudo ppa-purge ppa:owner/name

Utilisez ppa-purge avec prudence et lisez les changements proposés avant d’accepter, car il peut supprimer ou rétrograder plusieurs paquets connexes.

Après une mise à niveau de version

Après la mise à niveau d’Ubuntu, les anciens PPAs sont une source courante d’erreurs.

Vérifiez les anciens noms de code :

grep -R "jammy\|noble\|oracular\|plucky" /etc/apt/sources.list /etc/apt/sources.list.d/

Ajustez les noms de code pour votre système réel. Par exemple, si vous êtes sur Ubuntu 24.04, votre nom de code est noble. Si une source tierce pointe toujours vers un ancien nom de code, vérifiez si ce fournisseur prend en charge votre version actuelle d’Ubuntu. Si vous configurez une nouvelle machine plutôt que de réparer une mise à niveau, notre guide d’installation Ubuntu 24.04 explique comment ajouter des dépôts de fournisseurs avec signed-by dès le début.

Ne vous contentez pas de modifier le nom de code et d’espérer le meilleur — certains dépôts ne publient pas de paquets pour chaque version d’Ubuntu, donc vérifiez d’abord le support du fournisseur pour votre version.

Réparer les erreurs GPG et NO_PUBKEY

Ce que NO_PUBKEY signifie

Les dépôts APT publient des métadonnées signées, et votre machine a besoin de la clé publique correspondante pour vérifier ces métadonnées. Si la clé est manquante, APT refuse de faire confiance au dépôt, ce qui est le comportement souhaité — ne désactivez pas les vérifications de signature juste pour faire disparaître l’erreur.

Le modèle de trousseau de clés moderne

Créez le répertoire du trousseau de clés :

sudo install -d -m 0755 /etc/apt/keyrings

Téléchargez et déarmez la clé du fournisseur :

curl -fsSL https://example.com/repository-key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

Définissez les permissions de lecture :

sudo chmod 0644 /etc/apt/keyrings/example.gpg

Ajoutez le dépôt avec signed-by :

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/linux/ubuntu noble stable" \
  | sudo tee /etc/apt/sources.list.d/example.list

Ensuite, mettez à jour :

sudo apt update

Remplacez noble par votre nom de code Ubuntu si nécessaire :

. /etc/os-release
echo "$VERSION_CODENAME"

Pourquoi apt-key est une mauvaise habitude

Les anciens guides utilisent souvent :

curl -fsSL https://example.com/key.gpg | sudo apt-key add -

Évitez apt-key add pour les nouvelles configurations. L’ancien style apt-key ajoute des clés à une zone de confiance large, ce qui rend plus difficile la compréhension de quelle clé est de confiance pour quel dépôt, alors que le style moderne signed-by restreint la clé à un dépôt spécifique et constitue une hygiène de base de la chaîne d’approvisionnement.

Trouver les clés de confiance héritées

Vous pouvez encore avoir de vieilles clés dans :

/etc/apt/trusted.gpg
/etc/apt/trusted.gpg.d/

Listez les fichiers :

ls -l /etc/apt/trusted.gpg.d/

Ne supprimez pas les clés au hasard — mappez d’abord chaque clé à un dépôt, puis migrez un dépôt à la fois vers /etc/apt/keyrings et signed-by.

Erreurs GPG courantes

N’utilisez pas de serveurs de clés aléatoires comme premier choix lors de la réparation des erreurs NO_PUBKEY.

Meilleur ordre :

1. Utilisez la documentation d’installation officielle du fournisseur.
2. Téléchargez la clé depuis l’URL HTTPS officielle du fournisseur.
3. Stockez-la dans /etc/apt/keyrings.
4. Liez-la avec signed-by.
5. Exécutez sudo apt update.

Évitez ces raccourcis :

sudo apt update --allow-unauthenticated
sudo apt install --allow-unauthenticated package-name

Ils peuvent fonctionner temporairement, mais ils suppriment la vérification de signature qui vous protège contre les métadonnées de dépôt altérées.

Réparer “Le dépôt n’est pas signé”

Cette erreur signifie généralement l’un de ces éléments :

• Le dépôt ne publie pas de métadonnées signées.
• L’URL du dépôt est incorrecte.
• Le dépôt ne prend plus en charge votre version d’Ubuntu.
• Un proxy ou un miroir renvoie le mauvais contenu.
• Vous utilisez HTTP alors que le fournisseur attend désormais HTTPS.
• Le fichier source a la mauvaise suite ou composant.

Trouvez la source en échec :

sudo apt update

APT imprimera l’URL. Ensuite, recherchez-la :

grep -R "example.com" /etc/apt/sources.list /etc/apt/sources.list.d/

Désactivez-la temporairement :

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Si APT fonctionne à nouveau après avoir désactivé le fichier, réinstallez ce dépôt depuis les instructions officielles actuelles du fournisseur plutôt que de réactiver l’ancienne configuration.

Réparer les avertissements de dépôts en double

APT peut avertir qu’une cible est configurée plusieurs fois.

Listez les entrées correspondantes :

grep -R "repo-url-or-domain" /etc/apt/sources.list /etc/apt/sources.list.d/

Les dépôts en double apparaissent souvent après avoir exécuté plusieurs fois les scripts d’installation des fournisseurs.

Gardez un fichier source. Désactivez les autres :

sudo mv /etc/apt/sources.list.d/duplicate.list /etc/apt/sources.list.d/duplicate.list.disabled
sudo apt update

Les avertissements de duplication ne sont pas toujours fatals, mais ils sont le signe d’une configuration négligée, donc gardez un fichier source et désactivez les doublons.

Réparer les paquets de la mauvaise version d’Ubuntu

L’un des pires problèmes d’APT est le mélange des versions d’Ubuntu — par exemple, une machine sur Ubuntu 24.04 ne devrait pas tirer casually des paquets d’Ubuntu 22.04 ou de Debian testing. Parfois, cela fonctionne un moment, mais à la fin, le graphe de dépendances devient une énigme qu’APT ne peut pas résoudre proprement.

Vérifiez votre version :

. /etc/os-release
echo "$VERSION_CODENAME"

Recherchez les sources :

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

Recherchez des noms de code étrangers dans les sources activées, puis inspectez le paquet affecté :

apt-cache policy package-name

Si la version installée provenait d’un ancien ou d’un dépôt étranger, désactivez ce dépôt et rétrogradez ou réinstallez le paquet affecté depuis les dépôts Ubuntu.

Un chemin de réparation conservateur est :

sudo apt update
sudo apt install --reinstall package-name

Pour des conflits plus profonds, vous devrez peut-être supprimer le paquet et le réinstaller depuis la source correcte plutôt que de forcer une mise à niveau sur une version étrangère.

Nettoyage du cache APT et des paquets inutilisés

Le nettoyage du cache APT n’est pas une réparation de dépendance en soi, mais il peut aider après de nombreuses installations échouées en libérant de l’espace disque et en effaçant les fichiers de paquets obsolètes.

Supprimez les paquets qui ont été installés automatiquement et ne sont plus nécessaires :

sudo apt autoremove

Nettoyez les fichiers de paquets téléchargés :

sudo apt clean

Ou supprimez uniquement les fichiers de paquets obsolètes :

sudo apt autoclean

Utilisez autoremove avec prudence sur les serveurs et les bureaux avec des stacks de pilotes installés manuellement, et lisez la liste des suppressions avant d’accepter.

Recettes pratiques de dépannage APT

Recette : Le paquet est retenu (Kept Back)

sudo apt update
apt list --upgradable
apt-mark showhold
sudo apt full-upgrade

Si APT propose des changements raisonnables après la simulation, acceptez-les. S’il propose de grandes suppressions, arrêtez-vous et inspectez :

apt-cache policy package-name

Recette : Le paquet maintenu bloque la mise à niveau

apt-mark showhold
apt-cache policy package-name
sudo apt-mark unhold package-name
sudo apt upgrade

Ne retirez un maintien que si le maintien n’est plus intentionnel, car la suppression d’un maintien qui protège un logiciel de production peut déclencher une mise à niveau cassante.

Recette : Installation interrompue

sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt upgrade

Recette : Erreur NO_PUBKEY

1. Identifiez le dépôt depuis sudo apt update.
2. Trouvez les instructions d’installation officielles actuelles du fournisseur.
3. Installez la clé dans /etc/apt/keyrings.
4. Utilisez signed-by dans le fichier source.
5. Exécutez sudo apt update.

Structure d’exemple :

sudo install -d -m 0755 /etc/apt/keyrings

curl -fsSL https://example.com/key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

sudo chmod 0644 /etc/apt/keyrings/example.gpg

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/ubuntu noble main" \
  | sudo tee /etc/apt/sources.list.d/example.list

sudo apt update

Recette : Le PPA n’a pas de fichier Release

sudo apt update
ls /etc/apt/sources.list.d/
grep -R "ppa.launchpadcontent.net\|launchpad" /etc/apt/sources.list.d/

Désactivez le PPA :

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

Décidez ensuite s’il faut supprimer, remplacer ou purger les paquets de ce PPA.

Recette : Le .deb manuel a brisé les dépendances

dpkg -l | grep package-name
apt-cache policy package-name
sudo apt remove package-name
sudo apt --fix-broken install

Si vous avez toujours besoin du logiciel, préférez le dépôt APT actuel du fournisseur aux installations manuelles répétées de .deb, qui ont tendance à accumuler des conflits de dépendance avec le temps.

Commandes essentielles de dépannage APT

Dépôt et métadonnées

sudo apt update
grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/
ls /etc/apt/sources.list.d/

État des paquets

apt list --installed
apt list --upgradable
apt-mark showhold
dpkg -l | grep package-name

Politique et dépendances des paquets

apt-cache policy package-name
apt-cache depends package-name
apt-cache rdepends package-name

Réparation

sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt install --reinstall package-name
sudo apt full-upgrade

Nettoyage

sudo apt autoremove
sudo apt autoclean
sudo apt clean

Simulation

apt -s install package-name
apt -s full-upgrade

Ce qu’il ne faut pas faire

Ne supprimez pas aléatoirement /var/lib/dpkg

Si vous voyez des conseils pour supprimer les fichiers d’état de dpkg, soyez sceptique. La base de données dpkg est le registre des paquets installés, et la suppression de parties de celle-ci peut transformer un problème de paquet réparable en un projet de récupération de système complet.

Ne désactivez pas la vérification de signature

Évitez :

--allow-unauthenticated

Si un dépôt ne peut pas être vérifié, réparez la clé ou désactivez le dépôt plutôt que de contourner l’authentification.

Ne mélangez pas les versions d’Ubuntu casually

N’ajoutez pas de dépôts pour une autre version d’Ubuntu à moins que vous ne compreniez le verrouillage APT et les conséquences sur les dépendances.

Cela s’applique particulièrement à :

• les environnements de bureau
• les pilotes graphiques
• les stacks Python
• les environnements d’exécution de conteneurs
• les paquets Kubernetes
• les paquets de base de données

Ne traitez pas les PPAs comme inoffensifs

Les PPAs sont utiles, mais ce sont toujours des dépôts de paquets qui peuvent remplacer des bibliothèques et des paquets système — ce qui peut être exactement ce que vous voulez, ou exactement pourquoi votre prochaine mise à niveau échoue. Préférez les PPAs pour des applications spécifiques, pas pour des fondations système larges, sauf si vous faites confiance au mainteneur et que vous comprenez le chemin de mise à niveau.

Arbre de décision de dépannage APT

Utilisez ce modèle mental :

La plupart des problèmes APT deviennent gérables une fois que vous cessez de les traiter comme une grande erreur et commencez à séparer la santé du dépôt, l’état des paquets, la résolution des dépendances et la configuration de la confiance — l’arbre de décision ci-dessus est une abréviation de cette discipline.

Ligne de base recommandée pour les machines de développement

Pour une station de travail de développement Ubuntu propre, je préfère cette ligne de base :

• Conservez les dépôts Ubuntu standards.
• Utilisez les dépôts APT des fournisseurs uniquement s’ils sont officiels et maintenus.
• Utilisez /etc/apt/keyrings et signed-by pour les dépôts tiers.
• Évitez les anciennes instructions apt-key.
• Évitez de mélanger des PPAs qui remplacent les bibliothèques système de base.
• Utilisez des conteneurs, uv, pipx, asdf, mise ou des outils natifs au langage pour les dépendances de développement à évolution rapide.
• Gardez APT responsable du système d’exploitation, des pilotes, des services et des outils CLI stables.

Pour les logiciels de bureau, préférez Flatpak ou Snap aux PPAs lorsqu’un paquet universel sandboxé correspond à vos besoins. APT est excellent lorsqu’il gère le système de base, mais il devient pénible lorsqu’il est forcé de se comporter comme un gestionnaire de dépendances universel pour les écosystèmes de langages à évolution rapide.

Liste de contrôle finale de dépannage APT

Lorsqu’APT est brisé sous Ubuntu, parcourez cette liste de contrôle :

[ ] Exécutez sudo apt update et lisez la première vraie erreur.
[ ] Vérifiez le nom de code Ubuntu avec /etc/os-release.
[ ] Terminez les installations interrompues avec dpkg --configure -a.
[ ] Réparez les dépendances avec apt --fix-broken install.
[ ] Vérifiez les paquets maintenus avec apt-mark showhold.
[ ] Inspectez les versions des paquets avec apt-cache policy.
[ ] Désactivez les PPAs brisés ou les dépôts tiers.
[ ] Remplacez les dépôts de style apt-key par des trousseaux signed-by.
[ ] Simulez les opérations risquées avec apt -s.
[ ] Lisez les suppressions avant d'accepter full-upgrade ou autoremove.

APT n’est pas fragile, mais il est strict, et cette rigueur est une fonctionnalité : elle empêche les dépôts non signés, les ensembles de dépendances impossibles et les remplacements de paquets accidentels de modifier silencieusement votre système. La manière calme de réparer APT est de préserver cette rigueur, de trouver l’état conflictuel et de réparer la plus petite chose qui est réellement erronée.