DNF 5, Flatpak et la gestion des paquets sur RHEL 10

La gestion logicielle sur Red Hat Enterprise Linux 10 connaît la rupture la plus visible depuis RHEL 6. DNF 5, réécrit en C++ pour gagner en performance, devient le gestionnaire de paquets par défaut. Surtout, Red Hat ne distribue plus aucun contenu modulaire : la commande dnf module et la kickstart module sortent du périmètre. Les versions multiples de langages et bases de données passent par des paquets RPM directs au sein de l’AppStream classique. Flatpak vient compléter le tableau pour les applications graphiques de bureau. Ce tutoriel couvre l’ensemble pas à pas avec les commandes vérifiées sur RHEL 10.

Prérequis avant de commencer

• Un système RHEL 10, Rocky Linux 10 ou AlmaLinux 10 fonctionnel.
• Un accès sudo ou root.
• Une connexion réseau pour atteindre les dépôts officiels.
• Niveau attendu : débutant à intermédiaire. Temps estimé : 75 minutes.

Étape 1 — Vérifier la version de DNF

RHEL 10 livre DNF 5 par défaut. La commande historique yum reste disponible comme alias mais pointe désormais sur DNF 5. Vérifier la version permet de s’assurer qu’on travaille bien avec le nouveau moteur et non avec une installation legacy importée d’une migration depuis RHEL 9.

dnf --version
which dnf yum
rpm -qa | grep -E '^dnf'

La sortie de dnf --version doit afficher une version 5.x. Sur RHEL 9, on aurait vu une 4.x basée sur Python. La réécriture en C++ se traduit par un parseur de dépendances plus rapide, des transactions plus fluides sur les machines à RAM limitée et une consommation mémoire réduite. Les commandes utilisateur restent compatibles avec DNF 4 dans la grande majorité des cas, ce qui évite de réapprendre la syntaxe.

Étape 2 — Lister et inspecter les dépôts

Sur RHEL 10 enregistrée chez Red Hat, plusieurs dépôts sont disponibles dont les noms commencent par rhel-10-for-x86_64-baseos-rpms et rhel-10-for-x86_64-appstream-rpms. Ces deux dépôts couvrent l’essentiel de ce qu’un administrateur installera.

sudo dnf repolist                        # Dépôts activés
sudo dnf repolist --all                  # Tous les dépôts, activés ou non
sudo dnf repoinfo rhel-10-for-x86_64-baseos-rpms

La sortie de repolist donne pour chaque dépôt activé le nom, l’identifiant et le nombre de paquets. repolist --all ajoute les dépôts désactivés, utile quand on cherche pourquoi un paquet n’est pas trouvé. repoinfo détaille un dépôt précis : URL, nombre de paquets, date de mise à jour des métadonnées, taille des métadonnées. Un cache de métadonnées trop ancien explique la plupart des installations qui retournent nothing to do malgré une mise à jour disponible — la commande sudo dnf clean metadata && sudo dnf makecache rafraîchit immédiatement.

Étape 3 — Installer, mettre à jour, supprimer

Les opérations de base obéissent à une syntaxe lisible et permettent de manipuler plusieurs paquets à la fois.

sudo dnf install -y httpd vim-enhanced bash-completion
sudo dnf upgrade -y                      # Met à jour tout
sudo dnf upgrade -y httpd                # Met à jour uniquement httpd
sudo dnf remove -y httpd

Le drapeau -y répond yes automatiquement aux confirmations — utile dans les scripts mais à éviter en production sans réflexion. La commande upgrade remplace l’ancienne update ; les deux restent acceptées. remove retire le paquet et tente d’enlever ses dépendances qui ne servent à rien d’autre, sauf si elles ont été explicitement marquées comme installées par l’utilisateur — comportement parfois surprenant qu’il faut connaître. Pour ne désinstaller que le paquet sans toucher aux dépendances, rpm -e --nodeps nom reste l’outil bas niveau.

Étape 4 — Recherche et inspection

Trouver un paquet dans le catalogue ou retrouver à quel paquet appartient un fichier sont les deux opérations de recherche les plus courantes.

sudo dnf search nginx                    # Cherche dans noms et descriptions
sudo dnf info httpd                      # Détail d'un paquet
sudo dnf provides /usr/sbin/httpd        # Quel paquet fournit ce fichier
sudo dnf list installed | grep -i web    # Filtre les installés

provides est la commande qui sauve quand on a un binaire qui manque sans savoir quel paquet l’apporte — typiquement nslookup qui appartient à bind-utils, ou tcpdump qui appartient au paquet du même nom. La sortie liste tous les paquets qui contiennent le chemin demandé, avec leur version exacte. Combiné avec provides '*/*', on retrouve un fichier dont on ne connaît que le nom partiel.

Étape 5 — Groupes de paquets

DNF agrège des paquets en groupes sémantiques pour installer un environnement cohérent en une commande. Sur RHEL 10, les groupes incluent Server with GUI, Web Server, Development Tools et plusieurs autres.

sudo dnf group list
sudo dnf group info "Development Tools"
sudo dnf group install -y "Development Tools"
sudo dnf group remove "Development Tools"

La commande group list affiche les groupes disponibles, ceux installés et les groupes optionnels. group info détaille les paquets obligatoires, par défaut et optionnels d’un groupe. Sur les sujets EX200, l’installation de Development Tools revient régulièrement quand un script à compiler exige make, gcc et leurs dépendances. Cette commande économise plusieurs install individuels.

Étape 6 — Ajouter un dépôt tiers : EPEL

EPEL — Extra Packages for Enterprise Linux — fournit des paquets utiles non inclus dans la base RHEL : htop, iperf3, nethogs, rclone et bien d’autres. Sur RHEL 10, l’ajout d’EPEL passe par un paquet de configuration officiel.

sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm
sudo dnf repolist | grep -i epel
sudo dnf install -y htop iperf3

L’URL epel-release-latest-10 pointe automatiquement vers la dernière version du paquet EPEL pour RHEL 10. Si le téléchargement échoue, la cause est généralement un proxy ou un DNS bloquant — curl -I https://dl.fedoraproject.org permet de vérifier l’accès. Une fois EPEL activé, les paquets supplémentaires s’installent comme depuis n’importe quel dépôt avec dnf install.

Étape 7 — Historique et retour arrière

DNF garde la trace de chaque transaction. On peut consulter l’historique, examiner ce qu’une transaction a fait, et même annuler une mise à jour problématique.

sudo dnf history list                    # Liste des transactions
sudo dnf history info 42                 # Détail de la transaction n°42
sudo dnf history undo 42                 # Annule la transaction
sudo dnf history rollback 30             # Rembobine jusqu'à l'état au point 30

L’historique offre une vue chronologique des installations, mises à jour et suppressions. undo annule une transaction précise — utile quand on a installé un paquet qui a cassé un service. rollback rembobine plusieurs transactions d’un coup pour retrouver un état antérieur connu sain. Ces opérations modifient des dépendances ; leur succès n’est pas garanti si des paquets installés ultérieurement en dépendent. La commande retourne alors une erreur claire avant toute modification.

Étape 8 — La fin des modules DNF sur RHEL 10

Sur RHEL 8 et RHEL 9, les modules permettaient d’installer plusieurs versions d’un langage ou d’une base de données coexistant sur la même machine via la commande dnf module. RHEL 10 supprime cette mécanique. Red Hat ne distribue aucun contenu modulaire dans RHEL 10. Les commandes dnf module list, dnf module enable, dnf module install retournent une liste vide ou des erreurs, et la kickstart module est dépréciée par Anaconda.

# Tester la situation actuelle
sudo dnf module list 2>&1 | head -10
# Sortie : Nothing to display

Les versions multiples sont désormais empaquetées en RPM directs. Par exemple, Python 3.12, 3.13 et 3.14 cohabitent comme paquets python3.12, python3.13, python3.14 dans l’AppStream sans passer par les modules. Pour les administrateurs migrant depuis RHEL 8 ou 9, la conséquence pratique est positive : la complexité conceptuelle des streams et profils disparaît, remplacée par des paquets RPM standard. Les scripts kickstart qui utilisaient module --name=postgresql --stream=15 doivent être réécrits pour installer directement le paquet postgresql-15 ou la version la plus récente disponible dans l’AppStream RHEL 10.

Étape 9 — Flatpak pour les applications graphiques

Flatpak complète DNF côté applications utilisateur, sans toucher au système. Il permet d’installer des applications de bureau modernes — typiquement Firefox, LibreOffice, GIMP, ou des éditeurs spécialisés — dans des bacs à sable isolés avec leurs propres dépendances. C’est utile quand l’application requise n’est pas disponible en RPM ou disponible uniquement dans une version trop ancienne.

sudo dnf install -y flatpak
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak remote-list
flatpak search firefox
flatpak install -y flathub org.mozilla.firefox
flatpak run org.mozilla.firefox

Le dépôt Flathub n’est pas activé par défaut sur RHEL 10 ; on l’ajoute manuellement. La première installation télécharge un runtime partagé que les applications suivantes réutilisent, ce qui amortit la consommation disque sur plusieurs applications. Les applications Flatpak n’apparaissent pas dans dnf list installed parce qu’elles ne sont pas gérées par DNF — la commande dédiée est flatpak list. Sur un serveur sans interface graphique, Flatpak n’a aucun intérêt et n’est pas à installer.

Étape 10 — Vérifier l’état système

sudo dnf check                           # Cohérence des dépendances
sudo dnf needs-restarting                # Services à redémarrer après upgrade
sudo dnf list extras                     # Paquets installés sans dépôt source
sudo dnf list duplicates                 # Doublons à nettoyer

check détecte les ruptures de dépendances et les conflits — opération à exécuter après une migration ou avant une mise à jour majeure. needs-restarting liste les services qui tournent encore avec une bibliothèque mise à jour et n’ont pas été redémarrés ; un systemctl restart ciblé suffit à appliquer les correctifs sans reboot. list extras identifie les paquets dont le dépôt source n’est plus configuré, qui resteraient orphelins en cas de problème.

Erreurs fréquentes

Adaptation aux serveurs à bande passante limitée

Sur des liens internet lents, les transferts de paquets pèsent vite. Trois pratiques aident. La première consiste à activer fastestmirror dans /etc/dnf/dnf.conf pour que DNF sélectionne automatiquement le miroir le plus rapide à chaque transaction. À noter : DeltaRPM, autrefois utile pour télécharger uniquement les différences entre versions, n’est plus pris en charge par DNF 5 et a été retiré des dépôts officiels — l’option ne sert plus à rien sur RHEL 10. La deuxième consiste à mettre en place un cache local dnf reposync sur un serveur du réseau et à pointer les autres machines dessus avec un fichier .repo personnalisé. La troisième consiste à programmer les upgrade automatiques avec dnf-automatic en heure creuse.

Tutoriels frères

• Maîtriser systemd : units, timers et targets sur RHEL 10
• Dépanner le démarrage et entrer en rescue sur RHEL 10

Pour explorer plus loin

• 🔝 Retour à l’article principal : RHCSA EX200 v10 : la voie d’entrée Linux entreprise
• Documentation officielle : Managing software with the DNF tool RHEL 10
• Considerations in adopting RHEL 10 — détails sur la fin des modules
• Flathub — catalogue Flatpak

Questions fréquentes

Faut-il encore apprendre yum ?

Non. Sur RHEL 10, yum est un alias de dnf, et le projet Yum upstream est déprécié depuis longtemps. Apprendre directement dnf évite la confusion et reflète la réalité de la production moderne.

EPEL est-il fiable pour la production ?

EPEL est maintenu par la Fedora SIG, n’est pas couvert par le support Red Hat, et reste néanmoins largement utilisé en production pour des outils complémentaires comme htop ou jq. Les paquets EPEL respectent en général les mêmes conventions de packaging que les RPM officiels.

Comment fixer la version d’un paquet pour empêcher sa mise à jour ?

Le plugin dnf-plugins-core fournit dnf versionlock. La commande sudo dnf versionlock httpd-2.4.62 empêche la mise à jour vers une version plus récente jusqu’à ce que l’on retire le verrou avec versionlock delete.

Flatpak peut-il remplacer DNF complètement ?

Non. Flatpak est conçu pour les applications de bureau utilisateur. Le système de base, les services, les bibliothèques système restent gérés par DNF. Les deux outils sont complémentaires.

Comment migrer un script qui utilisait dnf module enable ?

Identifier la version exacte requise par le script. Vérifier dans dnf list available 'nom-version*' que le RPM direct existe sur RHEL 10. Remplacer la commande dnf module enable nom:version et dnf install nom par un seul dnf install nom-version.

Comment savoir si un paquet est obsolète après upgrade RHEL 10 ?

La commande sudo dnf list extras liste les paquets installés dont le dépôt source n’existe plus dans la configuration courante — typiquement les paquets venus d’un dépôt désactivé. Ces paquets sont candidats à la suppression manuelle ou à la réinstallation depuis un dépôt actuel.