CyberSDF

Reprenez la main sur votre numérique

Rédigé par Rédaction CyberSDF /

apt unmet dependencies : « but it is not going to be installed »

une machine de bureau ouverte posee sur un etabli, cables ranges, tournevis pose a plat

sudo apt install mon-paquet s’arrête sur The following packages have unmet dependencies:, puis sur une ligne Depends: libexemple1 but it is not going to be installed. Ce verdict sort du calcul d’APT : la dépendance figure dans l’index, et le calcul a décidé de ne pas l’installer avec le paquet demandé. Les messages et les options cités viennent d’APT 3.0.3 et de dpkg 1.22.22, les versions livrées par Debian 13. D’autres dépannages de paquets sont regroupés dans la rubrique Debian.

Sommaire
  1. Cinq étapes rendent une dépendance « not going to be installed » installable
  2. Sous Debian 13, apt et apt-get n’écrivent plus le même intitulé
  3. « but it is not installable » et « but it is not going to be installed » ne désignent pas la même panne
  4. Une dépendance logée dans backports n’est choisie que si le dépôt est épinglé
  5. Ce que –fix-broken ne répare pas
  6. Le hold, l’épinglage et le nettoyage du cache tranchent les cas qui résistent
  7. Sources

Cinq étapes rendent une dépendance « not going to be installed » installable

APT refuse une installation plutôt que de laisser le système incohérent : la page apt-get(8) écrit qu’une dépendance cassée ne peut pas exister sur un système et qu’une structure abîmée peut exiger une intervention manuelle, souvent dpkg --remove sur les paquets fautifs. La réparation suit toujours le même ordre : nommer le paquet réclamé, contrôler l’état de la base dpkg, terminer les configurations interrompues, installer la dépendance par son nom, chercher enfin les blocages silencieux. Les cinq étapes ci-dessous se lancent dans cet ordre, et chacune se termine par la sortie qui confirme qu’elle a abouti.

  1. Nommer la dépendance réclamée et la version que les dépôts en proposent.

    apt-cache policy libexemple1

    À l’écran : les lignes Installed: et Candidate:, puis la table des versions disponibles avec leur priorité et le dépôt qui les porte. La page apt-cache(8) présente policy comme l’outil de débogage des préférences : c’est ici que se voit si un dépôt fournit la dépendance.

  2. Vérifier l’état de la base dpkg et l’absence de dépendances cassées.

    sudo apt-get check
sudo dpkg --audit

    À l’écran : rien du tout dans le cas sain. La page dpkg(1) décrit --audit comme un contrôle de cohérence, qui liste les paquets partiellement installés et suggère la correction ; la page apt-get(8) définit check comme un outil de diagnostic qui cherche les dépendances cassées.

  3. Terminer les configurations en souffrance, puis laisser APT recalculer l’ensemble.

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

    À l’écran : une ligne Setting up nom-du-paquet (version) ... par paquet repris. La page dpkg(1) réserve --configure -a aux paquets déballés mais non configurés, et la page apt-get(8) décrit --fix-broken comme la correction d’un système aux dépendances cassées.

  4. Installer la dépendance sous son nom, puis relancer la demande d’origine.

    sudo apt install libexemple1
sudo apt install mon-paquet

    À l’écran : le récapitulatif qui annonce libexemple1, sa récupération, puis la seconde commande qui installe mon-paquet sans nouvelle ligne Depends:. Nommer la dépendance la marque comme installée manuellement, ce que décrit la page apt-mark(8) : elle échappe ainsi au nettoyage automatique.

  5. Chercher les deux causes qui ne laissent aucune trace dans le journal d’installation.

    apt-mark showhold
apt-cache policy mon-paquet

    À l’écran : rien pour la première commande quand aucun paquet n’est en attente, sinon un nom par ligne ; pour la seconde, la priorité de chaque version. La page apt-mark(8) définit hold comme le blocage des changements automatiques d’un paquet, et unhold pour lever ce blocage.

Sous Debian 13, apt et apt-get n’écrivent plus le même intitulé

Le blocage est identique, l’en-tête ne l’est plus. Dans le code d’APT 3.0.3, une option interne, APT::Output-Version, est comparée au niveau 30 : en dessous, l’intitulé est The following packages have unmet dependencies:, à partir de ce niveau, c’est Unsatisfied dependencies:. Le binaire apt positionne ce niveau à 30, apt-get le laisse à zéro, d’où deux sorties pour un seul incident. Sous Debian 12, le fichier correspondant d’APT 2.6.1 ne contient pas cette comparaison : les deux commandes gardent l’ancien intitulé, et les réponses de forum ne correspondent plus.

The following packages have unmet dependencies:
    exim: Depends: libc6 (>= 2.1.94) but 2.1.3-10 is to be installed
          Depends: libldap2 (>= 2.0.2-2) but it is not going to be installed
          Depends: libsasl7 but it is not going to be installed

Cet exemple est le commentaire qui décrit la sortie attendue dans private-output.cc, un fichier du dépôt d’APT. Le corps du message ne bouge pas : Depends: paquet but it is not going to be installed. Une machine en français reçoit la traduction du catalogue : mais ne sera pas installé sur cette ligne, et Impossible de corriger les problèmes, des paquets défectueux sont en mode « garder en l'état ». pour l’échec final.

« but it is not installable » et « but it is not going to be installed » ne désignent pas la même panne

Les deux formules sortent de la même fonction d’affichage et ne disent pas la même chose. Le code d’APT 3.0.3 teste la présence d’une version candidate : sans candidate, la ligne affichée est but it is not installable, ou but it is a virtual package quand le nom est fourni par d’autres paquets ; avec une candidate, la ligne devient but it is not going to be installed, ce qui signifie qu’une version existe et que le calcul l’a écartée. Cette différence oriente le diagnostic vers les dépôts ou vers le calcul.

Quatre lignes de sortie d’APT 3.0.3, leur cause et la commande qui la confirme
Message affiché Cause Commande de contrôle Sortie qui confirme la cause
Depends: libexemple1 but it is not going to be installed une version candidate existe et le calcul l’écarte apt-cache policy libexemple1 une ligne Candidate: renseignée, avec priorité et dépôt
Depends: libexemple1 but it is not installable aucune version candidate dans les dépôts configurés apt-cache policy libexemple1 une table de versions vide
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. un paquet en attente bloque le calcul apt-mark showhold le nom du paquet, un par ligne
E: Unable to correct problems, you have held broken packages. le calcul se termine avec au moins un paquet cassé dpkg --audit le paquet fautif et la réparation suggérée

Le mot held de la dernière ligne ne suppose aucun hold posé : le code renvoie cette erreur dès que le résolveur laisse au moins un paquet cassé. Quand c’est bien un hold qui bloque, apt-mark showhold le repère : tout paquet affiché se libère avec sudo apt-mark unhold nom-du-paquet. La page apt-get(8) documente aussi --ignore-hold, qui écarte les mises en attente le temps d’une commande.

Une dépendance logée dans backports n’est choisie que si le dépôt est épinglé

APT classe chaque version disponible par priorité et retient la plus haute. La page apt_preferences(5) d’APT 3.0.3 fixe les valeurs par défaut : priorité 500 pour une version non installée, 100 pour la version déjà installée, priorité 1 pour une archive marquée NotAutomatic: yes, comme expérimental, et 100 pour une archive qui porte aussi ButAutomaticUpgrades: yes, cas de Debian backports. Une dépendance fournie par le seul dépôt annexe reste donc sous le seuil des 500. Deux gestes la rendent candidate : -t bookworm-backports, que la page apt-get(8) décrit comme un épinglage à la priorité 990, ou un enregistrement dans /etc/apt/preferences.d/.

Le nom du fichier de préférences obéit à une règle que la page apt_preferences(5) énonce : aucune extension, ou l’extension pref, et des caractères limités aux lettres, chiffres, tirets, soulignés et points. Un fichier 99-monpin.conf est ignoré, avec un message d’APT. Une priorité négative empêche une version d’être installée, la valeur zéro a un comportement indéfini, et un épinglage mal écrit rend des paquets ininstallables, avertit la même page. Les fichiers de dépôts qui alimentent ce calcul se déclarent dans les dépôts APT.

Ce que –fix-broken ne répare pas

Deux limites écrites dans les sources expliquent les blocages qui résistent. La page apt-get(8) prévient qu’une structure de dépendances trop abîmée peut exiger une intervention manuelle, le plus souvent dpkg --remove sur les paquets fautifs ; elle documente aussi --no-remove, qui fait échouer la commande dès qu’une suppression de paquet est prévue, de quoi refuser une réparation qui emporterait un logiciel utile. De son côté, APT ne présente qu’un scénario : quand il n’en trouve pas, il s’arrête sur le message final.

Aptitude fait l’inverse. Sa page aptitude(8), version 0.8.13-7 dans trixie, distingue un résolveur prudent, qui n’enlève aucun paquet et n’installe aucune version autre que la candidate, d’un résolveur complet qui enlèvera volontiers des paquets pour satisfaire les dépendances. La commande aptitude why-not nom-du-paquet affiche la chaîne de dépendances qui mène au conflit, là où APT s’arrête sur une liste. Du côté de la FAQ Debian, apt-get reste l’outil recommandé pour un changement de version de Debian, décrit dans installer et mettre à jour Debian ; le reste du dépannage passe par l’administration Debian.

Le hold, l’épinglage et le nettoyage du cache tranchent les cas qui résistent

Que risque une réparation forcée avec –allow-change-held-packages ?

La page apt-get(8) qualifie cette option de dangereuse, à réserver à des situations très particulières, avec le risque de détruire le système : elle laisse passer les changements sur un paquet en attente sans confirmation. Le geste réversible tient en trois commandes : sudo apt-mark unhold nom-du-paquet, l’installation, puis sudo apt-mark hold nom-du-paquet. Ce même avertissement couvre --force-yes, que la page remplace par les options --allow-.

apt-cache policy ou aptitude why-not : laquelle interroger en premier ?

apt-cache policy libexemple1 répond sur la version : candidate, priorités, dépôt. aptitude why-not libexemple1 répond sur le conflit : la page aptitude(8) lui fait afficher la chaîne de dépendances qui aboutit au blocage, là où APT ne montre que la liste des dépendances non satisfaites. La seconde commande retourne 1 quand aucune explication n’est trouvée, et aptitude s’installe avec sudo apt install aptitude.

Comment détecter l’échec d’une installation dans un script ?

La page apt-get(8) fixe le code de retour à zéro en fonctionnement normal et à 100 en erreur, ce qui suffit à conditionner la suite : sudo apt-get install -y libexemple1 || echo "échec de la dépendance". Ce code se relit avec echo $? juste après la commande. dpkg abandonne de son côté après 50 erreurs, seuil que la page dpkg(1) laisse modifier avec --abort-after.

Pourquoi une dépendance disponible dans bookworm-backports reste-t-elle écartée ?

Parce que sa priorité vaut 100, contre 500 pour une version non installée des dépôts principaux, d’après la page apt_preferences(5) d’APT 3.0.3 : apt-cache policy mon-paquet montre les deux côte à côte. L’épinglage se pose pour une commande avec sudo apt install -t bookworm-backports mon-paquet, ou durablement par un fichier sans extension dans /etc/apt/preferences.d/.

Que reste-t-il dans /var/cache/apt/archives après une réparation ?

Les fichiers .deb récupérés pour combler la dépendance y restent ; leur taille cumulée se lit avec du -sh /var/cache/apt/archives. La page apt-get(8) décrit clean comme le vidage de tout ce dossier, seul le fichier de verrouillage étant conservé, et autoclean comme le nettoyage des fichiers qui ne peuvent plus être téléchargés. Les paquets installés ne bougent pas : sudo apt clean libère l’espace du cache.

Sources