Dpkg sous Linux : installer un paquet .deb sans bloquer APT derrière

Installer un fichier .deb à la main sous Debian ou Ubuntu, ça dépanne vite. Le piège, c’est de lancer dpkg -i, de voir une erreur de dépendances, puis de forcer au hasard jusqu’à laisser APT dans un état bancal.

Dans cet article, je vous montre une méthode propre : inspecter le paquet, l’installer avec dpkg, réparer les dépendances avec APT si besoin, puis vérifier ce qui a réellement été posé sur la machine.

Tux tenant un paquet Debian avec des symboles de dépendances réparées sous Linux — Installer un paquet .deb avec dpkg demande surtout de contrôler les dépendances et l’état APT.

Quand utiliser dpkg au lieu d’APT ?

dpkg est l’outil de bas niveau qui installe, configure, supprime et interroge les paquets Debian. APT est plus confortable, car il sait aller chercher les dépendances dans vos dépôts. C’est pour ça que, dans la plupart des cas, je garde APT comme premier choix.

dpkg devient utile quand vous avez déjà un fichier .deb local : paquet téléchargé depuis un éditeur, pilote, agent de supervision, outil interne, ou installation sur une machine qui n’a pas accès au dépôt complet. Dans ce cas, il faut juste garder une idée simple en tête : dpkg n’ira pas résoudre les dépendances tout seul.

Si le paquet vient d’un dépôt officiel accessible, utilisez plutôt APT. J’ai déjà détaillé la logique dans le guide sur la gestion des paquets avec APT sous Linux.

Inspecter le fichier .deb avant installation

Avant d’installer un paquet local, vérifiez d’abord ce qu’il contient. Ce n’est pas une formalité : un nom de fichier propre ne garantit rien.

dpkg -I ./mon-paquet.deb

dpkg -c ./mon-paquet.deb | less

La première commande affiche les métadonnées du paquet : nom, version, architecture, dépendances déclarées, mainteneur. La seconde liste les fichiers qui seront déployés. Sur un serveur, je regarde surtout si le paquet va écrire dans /etc, installer un service systemd, ou déposer un binaire dans un chemin sensible.

Vérifiez aussi l’architecture de la machine si vous avez un doute :

dpkg --print-architecture

uname -m

Un paquet amd64 ne s’installe pas proprement sur n’importe quelle architecture. Si vous forcez ici, vous gagnez rarement du temps.

Installer le paquet avec dpkg

Placez-vous dans le dossier qui contient le fichier, puis lancez l’installation :

cd ~/Téléchargements

sudo dpkg -i ./mon-paquet.deb

Si tout est déjà disponible sur le système, le paquet s’installe et se configure. Si une dépendance manque, dpkg peut laisser le paquet en état unpacked ou half-configured. C’est normal : il a copié une partie des fichiers, mais il n’a pas pu terminer la configuration.

Ne relancez pas la même commande dix fois. Lisez l’erreur, notez le nom du paquet concerné, puis laissez APT réparer la situation.

Réparer les dépendances sans casser APT

Sur Debian ou Ubuntu, la commande la plus utile après une erreur de dépendances est celle-ci :

sudo apt --fix-broken install

Vous pouvez aussi rencontrer l’ancienne forme :

sudo apt-get -f install

APT va relire l’état des paquets, proposer d’installer les dépendances manquantes ou de retirer ce qui bloque. Lisez la proposition avant de valider, surtout sur une machine de production. Si APT veut supprimer un gros morceau du système, arrêtez-vous et revenez à l’erreur de départ.

Si un paquet est simplement dépaqueté mais pas configuré, tentez aussi :

sudo dpkg --configure -a

sudo dpkg --audit

dpkg --audit est pratique pour repérer les paquets partiellement installés. Je l’utilise après une installation interrompue, une coupure SSH, ou une mise à jour stoppée trop tôt.

Vérifier que le paquet est bien installé

Une installation réussie ne se résume pas à une commande qui termine sans erreur. Vérifiez le statut du paquet :

dpkg -s nom-du-paquet

dpkg -l | grep nom-du-paquet

Pour savoir quels fichiers ont été installés :

dpkg -L nom-du-paquet

Et si le paquet installe un service, contrôlez-le immédiatement :

systemctl status nom-du-service --no-pager

journalctl -u nom-du-service -b --no-pager

Sur un serveur, c’est souvent là que le vrai problème apparaît : service qui ne démarre pas, fichier de configuration absent, port déjà utilisé, ou dépendance applicative non couverte par le paquet.

Installer un .deb avec APT peut être plus propre

Si la machine a accès à ses dépôts, vous pouvez installer un fichier local avec APT :

sudo apt install ./mon-paquet.deb

Cette méthode garde l’avantage du fichier local, mais APT peut résoudre les dépendances depuis les dépôts configurés. Pour un poste Debian ou Ubuntu classique, c’est souvent plus propre que dpkg -i suivi d’une réparation.

Je garde dpkg -i pour les cas où je veux vraiment contrôler l’étape de dépaquetage, ou quand je travaille dans un contexte plus contraint. Pour une installation simple, apt install ./fichier.deb évite déjà pas mal d’allers-retours.

Avant de multiplier les paquets téléchargés à la main

Un paquet .deb installé à la main doit rester l’exception, pas devenir une stratégie de mise à jour. Si vous empilez des paquets hors dépôt, vous perdez vite la visibilité sur les versions, les correctifs et les dépendances.

Avant de le faire sur un serveur, gardez au minimum cette séquence :

vérifier la source du paquet ;
inspecter les métadonnées avec dpkg -I ;
installer avec apt install ./paquet.deb si les dépôts sont disponibles ;
sinon installer avec dpkg -i, puis réparer avec APT si nécessaire ;
contrôler le statut avec dpkg -s, dpkg --audit et les logs du service.

Si le paquet touche Docker, un agent système ou un service réseau, vérifiez aussi le pare-feu et les ports ouverts. Le guide sur les ports ouverts sous Linux avec ss et netstat est utile juste après l’installation.

Sources utiles : manuel dpkg, manuel apt-get Debian et manuel dpkg-query.