DNF : gérer les paquets sur les distributions RPM

Cet article explique ce qu'est DNF, comment il fonctionne sous le capot, et comment l'utiliser concrètement sur Fedora, RHEL, Rocky Linux et AlmaLinux. Il s'adresse à quiconque gère des paquets sur une distribution basée sur RPM et veut comprendre pourquoi les commandes sont ce qu'elles sont, pas seulement les recopier.

Ce que DNF fait réellement

DNF signifie Dandified YUM. Le nom trahit son origine : c'est le successeur de YUM (Yellow Dog Updater, Modified), l'outil historique de gestion de paquets sur les distributions RPM. DNF est né pour corriger les limites techniques de YUM, notamment sur la résolution des dépendances complexes et la consommation mémoire.

Le travail central de DNF est simple à décrire : il interroge des dépôts (repositories), télécharge des paquets RPM, les installe, les met à jour ou les supprime, et résout automatiquement toutes les dépendances nécessaires. Sans lui, tu installerais chaque bibliothèque à la main dans le bon ordre. Avec lui, tu tapes une commande et tu obtiens un système cohérent.

DNF s'appuie sur le format RPM lui-même, et sur une bibliothèque centrale appelée libdnf. C'est cette bibliothèque qui analyse les métadonnées des paquets, calcule les dépendances et exécute les transactions. La séparation compte : une interface graphique ou un outil tiers peut utiliser libdnf sans passer par la ligne de commande. C'est ce qui permet à des environnements de bureau d'avoir leur propre gestionnaire de paquets visuel au-dessus du même moteur.

Prérequis

Avant de manipuler DNF, vérifie ton environnement :

• Une distribution RPM-based : Fedora (22 et plus), RHEL 8 ou 9, Rocky Linux 8 ou 9, AlmaLinux 8 ou 9.
• Un accès `root` ou `sudo` pour les opérations qui modifient le système.
• Une connexion réseau vers les dépôts configurés dans `/etc/yum.repos.d/`.
• Sur Fedora 41 et plus, c'est DNF5 qui est installé par défaut. Sur les versions antérieures de Fedora et sur RHEL/Rocky/AlmaLinux 8-9, c'est la version Python de DNF.

Cette distinction DNF classique / DNF5 est importante. DNF5 est une réécriture complète en C++, là où l'ancien DNF était écrit en Python. Le but : de meilleures performances, une empreinte mémoire plus faible, et une base de code plus facile à maintenir.

Vérifier la version installée

Avant tout, sache avec quoi tu travailles. La sortie diffère selon la génération.

```bash dnf --version ```

Sur un système DNF5 (Fedora 41+), tu verras une ligne du type `dnf5 version 5.x.x`. Sur l'ancien DNF, tu verras `4.x.x` avec la mention `dnf-4.x.x`. Cette information détermine quelles options sont disponibles : DNF5 a retiré certaines commandes obsolètes et en a ajouté d'autres.

Les commandes de base

1. Rechercher un paquet

```bash dnf search nginx ```

`dnf search` interroge les noms et descriptions des paquets disponibles dans tous les dépôts activés. C'est ta première étape quand tu ne connais pas le nom exact du paquet. La recherche porte sur les métadonnées en cache, pas sur le réseau, donc elle est rapide une fois le cache rempli.

2. Obtenir des informations sur un paquet

```bash dnf info nginx ```

`dnf info` affiche la version disponible, la taille, la licence, le dépôt d'origine et la description. Utile avant d'installer : tu vois immédiatement de quel dépôt vient le paquet et quelle version tu obtiendras.

3. Installer un paquet

```bash sudo dnf install nginx ```

DNF calcule les dépendances, te présente la liste de ce qui sera installé, et attend ta confirmation. Tu peux ajouter `-y` pour accepter automatiquement, ce qui est pratique dans un script mais dangereux en interactif : tu ne vois plus ce qui va être touché.

4. Mettre à jour le système

```bash sudo dnf upgrade ```

`dnf upgrade` met à jour tous les paquets installés vers leurs versions les plus récentes disponibles dans les dépôts. C'est l'équivalent de `apt upgrade` côté Debian. Sur un serveur de production, lance-le d'abord avec `--assumeno` pour voir ce qui changerait sans rien appliquer.

5. Supprimer un paquet

```bash sudo dnf remove nginx ```

`dnf remove` désinstalle le paquet et, selon le cas, les dépendances qui ne servent plus à rien. Attention : DNF te montrera ce qu'il compte retirer en plus du paquet cible. Lis cette liste avant de confirmer.

6. Nettoyer les dépendances orphelines

```bash sudo dnf autoremove ```

Quand tu supprimes un paquet, certaines de ses dépendances restent installées alors qu'aucun autre paquet ne les utilise. `dnf autoremove` les identifie et les retire. C'est le ménage. Sur un système qui tourne depuis longtemps, ça peut libérer plusieurs centaines de mégaoctets.

7. Gérer les dépôts

```bash dnf repolist ```

Cette commande liste tous les dépôts activés avec leur identifiant et leur nombre de paquets. Si un paquet que tu attends n'apparaît pas dans `dnf search`, la cause est souvent là : le dépôt qui le contient n'est pas activé.

Pour ajouter un dépôt, tu places un fichier `.repo` dans `/etc/yum.repos.d/`. Chaque fichier décrit une ou plusieurs sources avec leur URL de base, leur clé GPG et leur état activé ou non.

```bash sudo dnf config-manager --add-repo https://example.com/repo/example.repo ```

Sur DNF5, la syntaxe de `config-manager` a changé : elle est devenue une sous-commande distincte. Si tu obtiens une erreur sur Fedora 41+, vérifie la documentation de ta version avant de copier un tutoriel ancien.

8. Voir l'historique des transactions

```bash dnf history ```

Chaque installation, mise à jour ou suppression est enregistrée comme une transaction numérotée. C'est ce qui permet de revenir en arrière. Pour annuler une transaction précise :

```bash sudo dnf history undo ```

Cette fonction de rollback est l'un des arguments sérieux de DNF face à d'autres gestionnaires. Tu peux défaire une mise à jour qui a cassé quelque chose, à condition de ne pas avoir purgé l'historique entre-temps.

Vérifier que tout fonctionne

Après une installation, confirme que le paquet est bien présent et que le système est cohérent :

```bash rpm -q nginx sudo dnf check ```

`rpm -q` te donne la version exacte installée. `dnf check` parcourt les dépendances et signale toute incohérence. Si les deux commandes ne renvoient rien d'anormal, ton système est propre.

Pour un contrôle plus large après une mise à jour :

```bash sudo dnf updateinfo summary ```

Cela résume les avis de sécurité et les correctifs disponibles, ce qui te donne une idée de l'urgence réelle d'un `dnf upgrade`.

DNF dans l'écosystème RPM

DNF n'est pas propre à Fedora. Red Hat Enterprise Linux 8, sorti en 2019, a fait le passage de YUM à DNF comme gestionnaire par défaut. C'est le signal qui a confirmé que l'outil était assez mature pour la production. Comme RHEL est l'une des distributions enterprise les plus déployées, des millions de serveurs ont basculé sur DNF sans que leurs administrateurs le remarquent forcément : la compatibilité des commandes a rendu la transition invisible.

Les dérivés de RHEL ont suivi, puisque la compatibilité binaire 1:1 avec RHEL les y oblige. Rocky Linux utilise DNF avec des paquets RPM, et ses versions 8 et 9 suivent les mêmes principes que RHEL 8 et 9, avec compatibilité totale sur les dépôts officiels. AlmaLinux, porté par CloudLinux Inc., fait de même. Ces deux distributions visent le même créneau : remplacer CentOS après son changement de modèle.

Cette adoption en entreprise a une conséquence concrète. AlmaLinux dispose par exemple de la certification FIPS 140-3, exigée par certains secteurs réglementés. Le fait que DNF tourne dans des environnements certifiés à ce niveau indique à quel point l'outil est considéré comme stable. Ce n'est plus un projet expérimental.

Il y a une exception à connaître. Toutes les variantes de Fedora n'utilisent pas DNF de façon classique. Fedora Atomic Desktops et Fedora CoreOS reposent sur des systèmes immuables : l'installation entière est traitée comme une unité, et les mises à jour se font par transactions atomiques. Sur ces systèmes, le modèle de gestion paquet par paquet de DNF ne convient pas, et c'est rpm-ostree qui prend le relais. Si tu administres du CoreOS, n'essaie pas d'y appliquer les commandes de cet article.

Problèmes courants

Le paquet est introuvable dans les dépôts. Vérifie d'abord que le dépôt qui le contient est activé avec `dnf repolist`. Si le dépôt manque, ajoute son fichier `.repo` dans `/etc/yum.repos.d/`, puis rafraîchis le cache :

```bash sudo dnf makecache ```

Une transaction échoue à cause d'un conflit de dépendances. C'est souvent le signe de dépôts tiers mal configurés qui proposent des versions incompatibles. Identifie le paquet en conflit dans le message d'erreur, puis désactive temporairement le dépôt fautif avec `--disablerepo=` le temps de l'installation.

Le cache est corrompu ou obsolète. Les métadonnées en cache peuvent être périmées après un changement de dépôt. Purge et reconstruis :

```bash sudo dnf clean all sudo dnf makecache ```

Ce qu'il faut retenir sur DNF5

Depuis Fedora Linux 41, DNF5 est la variante par défaut. La réécriture en C++ vise trois choses : de meilleures performances, une consommation mémoire réduite, et une base de code plus maintenable. DNF5 reste compatible avec les commandes et plugins existants, ce qui limite la casse pour les scripts déjà en place.

Cette compatibilité n'est pas totale pour autant. Certaines options anciennes ont disparu, et la syntaxe de quelques sous-commandes a bougé. Un script écrit pour DNF4 en 2018 peut très bien échouer sur Fedora 41 sans message évident.

Le réflexe utile : ne présume jamais de la version. Lance `dnf --version` sur chaque machine avant de déployer un script de gestion de paquets. Ce qui marche sur ton AlmaLinux 9 ne passera pas forcément sur un Fedora récent, et inversement.