Gestion des paquets sous Linux : apt, dpkg, dnf, rpm, dépôts et signatures

Un gestionnaire de paquets fait trois choses dont une simple copie de fichiers est incapable : il enregistre précisément quels fichiers appartiennent à quel logiciel, il sait ce dont chaque logiciel a besoin pour fonctionner, et il peut vérifier que ce que vous avez téléchargé correspond bien à ce que les mainteneurs ont publié. Tout le reste — les commandes, les caches, les formats de dépôt — n'existe que pour servir ces trois propriétés.

Deux familles d'outils dominent. Debian, Ubuntu et leurs dérivées utilisent des archives .deb, avec dpkg en dessous et apt au-dessus. Fedora, RHEL, Rocky Linux, AlmaLinux et SUSE utilisent des archives .rpm, avec rpm en dessous et dnf (ou zypper) au-dessus. Les vocabulaires diffèrent, les concepts non : ce guide les présente donc côte à côte et signale les endroits où le comportement diverge vraiment.

Ce que contient un paquet

Un paquet, c'est une archive plus des métadonnées. L'archive est l'arborescence de fichiers à décompresser, organisée selon les conventions décrites dans l'arborescence du système de fichiers : les binaires dans /usr/bin, les bibliothèques dans /usr/lib, la configuration dans /etc, la documentation et les pages de manuel dans /usr/share, les fichiers d'unité dans /usr/lib/systemd/system. Ce sont les métadonnées qui sont intéressantes :

• Identité — nom, version, numéro de release, architecture (amd64, arm64, noarch).
• Dépendances — ce qui doit être présent pour que le paquet fonctionne, généralement exprimé sous forme de capacités virtuelles comme libssl3 ou httpd-mmn plutôt que de noms de paquets, afin que des alternatives puissent les satisfaire.
• Conflicts, provides, replaces — la façon dont le paquet se situe par rapport aux autres.
• Scripts de mainteneur — de petits fragments de shell exécutés avant et après l'installation ou la suppression, qui créent des comptes système, génèrent des clés, rechargent systemd ou redémarrent un service.
• Liste des fichiers de configuration — les fichiers que le gestionnaire ne doit jamais écraser en silence, parce que vous les avez peut-être modifiés.
• Sommes de contrôle de chaque fichier installé.

Vous pouvez regarder à l'intérieur sans rien installer :

dpkg --info ./nginx_1.26.0-1_amd64.deb        # metadata
dpkg --contents ./nginx_1.26.0-1_amd64.deb    # file list
rpm -qip ./nginx-1.26.0-1.el9.x86_64.rpm      # metadata
rpm -qlp ./nginx-1.26.0-1.el9.x86_64.rpm      # file list

Cette liste de fichiers de configuration explique un comportement qui déroute les débutants. Quand une mise à jour apporte une valeur par défaut modifiée et que vous avez édité le fichier, Debian vous demande s'il faut garder votre version, la remplacer ou afficher les différences, tandis que RPM installe la nouvelle version à côté de la vôtre sous le nom *.rpmnew (ou sauvegarde la vôtre en *.rpmsave). Après toute mise à jour importante, il vaut la peine de lancer find /etc -name '*.rpmnew' -o -name '*.dpkg-dist'.

Les mêmes opérations dans deux dialectes

Trois points où la différence est réelle et pas seulement cosmétique. D'abord, apt update et apt upgrade sont deux étapes distinctes, et oublier la première est de loin la cause la plus fréquente des « package not found » ; dnf, lui, rafraîchit ses métadonnées selon son propre calendrier. Ensuite, apt upgrade refuse de supprimer le moindre paquet et retient donc toute mise à jour qui l'exigerait — apt full-upgrade (anciennement dist-upgrade) est la variante qui peut supprimer des paquets, et c'est elle qu'il faut pour un changement de version de la distribution. Enfin, dnf history enregistre chaque transaction et dnf history undo 42 en annule une, une capacité qui n'a pas d'équivalent direct dans apt.

$ dnf history list | head -4
ID     | Command line             | Date and time    | Action(s)      | Altered
------------------------------------------------------------------------------
    42 | install nginx php-fpm    | 2026-09-05 14:02 | Install        |   31
    41 | upgrade                  | 2026-09-01 03:11 | Upgrade        |  118

Installer les fichiers locaux via le frontal (apt install ./pkg.deb) plutôt qu'avec dpkg -i a son importance : le frontal récupère les dépendances, alors que dpkg vous laisse avec un paquet à moitié configuré et un apt --fix-broken install à lancer ensuite.

Les dépôts et la chaîne de confiance

Un dépôt est un répertoire HTTP qui contient des paquets et un index. L'index est signé avec la clé d'un mainteneur, et la somme de contrôle de chaque paquet y est enregistrée. Votre machine détient les clés publiques correspondantes ; la chaîne se déroule donc ainsi : la clé de confiance vérifie la signature de l'index, l'index contient la somme de contrôle, la somme de contrôle vérifie le paquet téléchargé. Qu'un seul maillon casse, et le gestionnaire de paquets refuse d'installer.

Sur Debian et Ubuntu, les sources se trouvent dans /etc/apt/sources.list.d/ et les clés dans /etc/apt/keyrings/. La bonne pratique actuelle associe une clé à une source avec signed-by, au lieu d'ajouter la clé à un trousseau global de confiance où elle pourrait signer n'importe quoi :

sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://download.example.com/gpg.key \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg
sudo chmod 0644 /etc/apt/keyrings/example.gpg

echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/example.gpg] \
https://download.example.com/debian bookworm main" \
  | sudo tee /etc/apt/sources.list.d/example.list
sudo apt update

L'ancienne commande apt-key add, dépréciée, écrit dans un trousseau global et a disparu des versions actuelles ; si les instructions d'un éditeur vous demandent encore de l'utiliser, elles sont obsolètes. Les versions récentes acceptent aussi un unique fichier .sources au format deb822, plus lisible, qui permet d'y embarquer directement la clé.

L'équivalent dans la famille RHEL est un fichier .repo dans /etc/yum.repos.d/ :

[example]
name=Example packages
baseurl=https://download.example.com/el9/$basearch/
enabled=1
gpgcheck=1
gpgkey=https://download.example.com/RPM-GPG-KEY-example

C'est la ligne gpgcheck=1 qui compte. La désactiver pour faire passer une installation, c'est ainsi qu'un miroir compromis ou corrompu finit en production. Si une clé est réellement introuvable, récupérez-la auprès de l'éditeur par un canal de confiance et importez-la avec rpm --import, plutôt que de désactiver la vérification.

Comme les noms de dépôt tels que bookworm-updates et el9 sont liés à une version de la distribution, mélanger des dépôts de versions différentes produit un système qu'aucun mainteneur n'a jamais testé. S'il vous faut un paquet plus récent, cherchez un dépôt de backports officiel (bookworm-backports) ou un flux de module (dnf module list postgresql) avant d'ajouter une source étrangère.

La résolution des dépendances et les dégâts qu'elle peut causer

Le rôle du résolveur est de trouver un ensemble de versions de paquets qui satisfait toutes les exigences déclarées. La plupart du temps, c'est invisible. Cela devient visible dans quelques situations bien identifiables.

Mises à jour retenues. apt upgrade signale « the following packages have been kept back » quand la nouvelle version exige d'installer un paquet supplémentaire ou d'en supprimer un existant. Lancez apt full-upgrade, ou installez le paquet concerné en le nommant explicitement et lisez ce qui est proposé.

État cassé ou à moitié configuré. C'est généralement la conséquence d'un dpkg -i sans ses dépendances, ou d'une mise à jour interrompue. Pour s'en sortir :

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

Versions en conflit provenant de deux dépôts. Vérifiez d'où vient une version candidate avant de l'installer :

$ apt policy nginx
nginx:
  Installed: 1.22.1-9
  Candidate: 1.26.0-1
  Version table:
     1.26.0-1 500
        500 https://download.example.com/debian bookworm/main amd64 Packages
 *** 1.22.1-9 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages

Le 500 est une priorité ; apt-cache policy et dnf repoquery --qf '%{name} %{version} %{reponame}' sont les outils qui répondent à la question « pourquoi ai-je obtenu cette version ? ».

Simuler avant de s'engager. Les deux frontaux peuvent montrer le plan sans l'exécuter, ce qui vaut la peine sur tout serveur un tant soit peu important :

apt-get install --dry-run some-package
dnf install --assumeno some-package
apt list --upgradable
dnf check-update

Bloquer, épingler et rétrograder

Il arrive qu'une version précise soit nécessaire — une base de données qui doit correspondre à une application, ou un pilote qui a régressé dans une version plus récente.

sudo apt install nginx=1.26.0-1          # exact version
sudo apt-mark hold nginx                 # exclude from future upgrades
apt-mark showhold
sudo apt-mark unhold nginx

sudo dnf install nginx-1.26.0-1.el9
sudo dnf downgrade nginx
sudo dnf versionlock add nginx           # needs the versionlock plugin

APT permet aussi un contrôle plus fin grâce aux fichiers d'épinglage (pinning) dans /etc/apt/preferences.d/, qui attribuent un numéro de priorité à un dépôt ou à un motif de paquets ; on peut ainsi faire venir un paquet des backports pendant que tout le reste demeure sur stable :

Package: postgresql*
Pin: release n=bookworm-backports
Pin-Priority: 990

Chaque blocage et chaque épinglage est une dette technique qui a un coût en sécurité, puisqu'il exclut le paquet des mises à jour de sécurité. Notez la raison et une date d'expiration en commentaire, et passez-les régulièrement en revue.

Qu'est-ce que ce paquet a réellement installé sur mon système ?

Les requêtes inverses sont le moyen de comprendre un serveur dont vous héritez.

dpkg -S /usr/sbin/nginx                      # which package owns this file
dpkg -L nginx | grep '^/etc'                 # its configuration files
dpkg --verify nginx                          # report files that differ from the package
apt-mark showmanual                          # packages you asked for, not pulled in
zcat /var/log/apt/history.log*.gz | less     # what was installed and when

rpm -qf /usr/sbin/nginx
rpm -ql nginx
rpm -V nginx                                 # verification: size, mode, checksum, owner
rpm -q --changelog nginx | head -30
rpm -qa --last | head                        # recently installed

dpkg --verify et rpm -V comparent chaque fichier installé aux sommes de contrôle enregistrées lors de l'installation. Une ligne de sortie comme S.5....T. c /etc/nginx/nginx.conf indique que la taille, la somme de contrôle et l'horodatage ont changé sur un fichier marqué comme fichier de configuration — c'est attendu. Les mêmes indicateurs sur un binaire de /usr/sbin ne le sont pas et méritent une investigation.

Maintenir une machine à jour

Les mises à jour de sécurité sont le travail de routine le plus rentable sur n'importe quel serveur. Les deux familles savent les appliquer sans intervention humaine.

# Debian / Ubuntu
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
sudo unattended-upgrade --dry-run --debug

# RHEL family
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
sudo dnf updateinfo list security

Configurez l'automatisation pour n'appliquer que les mises à jour de sécurité, et pour journaliser ce qu'elle a fait. Les redémarrages sont ce que l'on oublie : un OpenSSL corrigé ne sert à rien pour un processus qui tourne encore avec l'ancienne bibliothèque. needrestart sur Debian et needs-restarting -r sur RHEL indiquent quels services (ou si la machine entière) doivent être redémarrés. Les redémarrages automatiques doivent suivre un calendrier que vous maîtrisez, et non à 03:00 par défaut.

Quand il n'existe pas de paquet

Il arrive qu'un logiciel dont vous avez besoin ne soit pas empaqueté pour votre distribution, ou que la version empaquetée soit trop ancienne. La compilation depuis les sources suit un schéma bien rodé :

sudo apt install build-essential pkg-config libpcre2-dev libssl-dev zlib1g-dev
curl -fLO https://example.org/releases/widget-3.2.1.tar.gz
curl -fLO https://example.org/releases/widget-3.2.1.tar.gz.sha256
sha256sum -c widget-3.2.1.tar.gz.sha256
tar -xzf widget-3.2.1.tar.gz && cd widget-3.2.1
./configure --prefix=/usr/local
make -j"$(nproc)"
sudo make install

Installez sous /usr/local (le --prefix par défaut, précisément pour cette raison) ou dans /opt/widget-3.2.1, jamais par-dessus le /usr de la distribution. Vérifiez la somme de contrôle ou la signature avant de décompresser, gardez quelque part la liste des dépendances de compilation, et n'oubliez pas que vous venez de prendre à votre charge le suivi des bulletins de sécurité de ce projet — rien ne vous préviendra. checkinstall peut emballer un make install dans un .deb rudimentaire, pour qu'au moins la liste des fichiers soit enregistrée.

Snap, Flatpak et écosystèmes des langages

Deux formats plus récents empaquettent une application avec ses dépendances. Snap (Ubuntu) et Flatpak (multidistribution, orienté poste de travail) isolent tous deux l'application des bibliothèques du système, ce qui résout les conflits de versions et ajoute un bac à sable, au prix d'un surcroît d'espace disque, d'un premier démarrage plus lent et d'un second mécanisme de mise à jour à surveiller. C'est un choix raisonnable pour les applications de bureau et un mauvais choix par défaut pour les composants serveur, où le paquet de la distribution s'intègre mieux avec systemd, la journalisation et le reste de la machine.

Les gestionnaires de paquets des langages — pip, npm, Maven, Cargo, les modules Go — appartiennent à votre application, pas au système d'exploitation. La règle qui évite la plupart des ennuis : ne jamais faire sudo pip install dans le Python du système, car les outils de la distribution en dépendent. Utilisez un environnement virtuel, un node_modules local au projet, ou une image de conteneur construite comme décrit dans les fondamentaux de Docker. Les versions récentes de Python l'imposent d'elles-mêmes en refusant d'installer dans l'interpréteur système sans une option de contournement explicite.

Erreurs courantes

• Installer avec dpkg -i et s'arrêter là. Les dépendances ne sont pas récupérées ; utilisez apt install ./file.deb.
• Désactiver gpgcheck pour contourner une erreur. Vous venez de supprimer la seule défense contre un miroir falsifié.
• Mélanger des dépôts de versions différentes de la distribution. Cela fonctionne jusqu'au jour où la mise à jour d'une bibliothèque partagée casse la moitié du système.
• Laisser un blocage en place pour toujours. Les mises à jour de sécurité cessent d'arriver, sans bruit. Datez chaque blocage.
• Lancer apt upgrade sur une machine distante sans vérifier ce qui redémarre. SSH lui-même, ou la pile réseau, peuvent en faire partie ; utilisez un multiplexeur de terminal pour qu'une connexion perdue n'interrompe pas la transaction.
• sudo pip install ou sudo npm install -g sur un serveur. Les outils système et votre application partagent alors un même arbre de dépendances, et une mise à jour de l'un casse l'autre.
• Ignorer les fichiers *.dpkg-dist et *.rpmnew. Votre configuration s'écarte silencieusement de ce que le paquet attend désormais.

Points clés à retenir

• Un paquet, ce sont des fichiers plus des métadonnées : dépendances, scripts de mainteneur, liste des fichiers de configuration protégés et sommes de contrôle par fichier.
• apt/dpkg et dnf/rpm diffèrent bien plus par le vocabulaire que par les concepts ; le frontal résout les dépendances, l'outil de bas niveau traite une archive à la fois.
• La confiance dans un dépôt repose sur un index signé ; ajoutez les sources tierces avec une clé dédiée et signed-by, et ne désactivez jamais gpgcheck.
• apt policy, dnf repoquery et dnf history expliquent d'où vient une version et permettent d'annuler une transaction.
• Les blocages et les épinglages sont des exceptions délibérées, documentées et datées — ils bloquent les mises à jour de sécurité tant qu'ils existent.
• dpkg -S, rpm -qf, dpkg --verify et rpm -V transforment un serveur inconnu en quelque chose que vous pouvez auditer.
• Préférez les paquets de la distribution pour les composants système, les outils propres au projet pour les bibliothèques applicatives, et /usr/local ou /opt quand vous devez compiler vous-même.