apt vers dnf : équivalences sur Rocky et Fedora

La réponse courte

Passer d’apt à dnf est surtout un changement de vocabulaire. apt install nginx devient dnf install nginx. apt remove nginx devient dnf remove nginx. apt update n’a pas d’équivalent direct, car dnf actualise automatiquement les métadonnées de ses dépôts lorsque la copie en cache devient obsolète. La moitié simple de la conversion tient sur un écran. La moitié utile concerne les quatre opérations qui ne correspondent pas directement : ajouter un dépôt, annuler une transaction, installer un groupe de paquets et exécuter des mises à jour sans intervention.

Toutes les commandes ci-dessous sont prévues pour être exécutées sur votre propre serveur. Lisez le récapitulatif de la transaction affiché par dnf avant de répondre à y, en particulier lors des suppressions.

Quelles distributions utilisent dnf et lesquelles utilisent apt

dnf est le gestionnaire de paquets de Fedora, de Red Hat Enterprise Linux (RHEL) et des reconstructions de RHEL : Rocky Linux, AlmaLinux et CentOS Stream. apt est le gestionnaire de paquets de Debian et de tout ce qui en dérive, ce qui signifie presque toujours Ubuntu sur un VPS. Il n’y a pas de troisième réponse. Si la liste d’images de votre fournisseur propose Rocky Linux ou AlmaLinux, vous utilisez dnf. Si elle propose Ubuntu, vous utilisez apt. Pourquoi un côté de cette séparation porte quatre noms pour désigner un système en grande partie identique est une histoire qu’il vaut la peine de connaître avant de choisir entre eux, et comment Red Hat Linux est devenu Fedora, RHEL, CentOS, Rocky et AlmaLinux explique l’origine de chacun.

Le format des paquets dépend de l’outil. dnf installe des fichiers .rpm et utilise une base de données rpm. apt installe des fichiers .deb et utilise une base de données dpkg. C’est pourquoi de nombreuses pages d’installation des éditeurs proposent un onglet pour chaque famille, et pourquoi un fichier .deb téléchargé depuis la page des releases d’un projet ne sert à rien sur Rocky Linux.

Quelle que soit la famille choisie, la première connexion demande les mêmes opérations. Les dix premières minutes sur un nouveau VPS s’appliquent aux deux. Seule la commande d’installation change.

Chaque commande apt et son équivalent dnf

Installer, supprimer, rechercher et afficher. Les commandes utilisent presque les mêmes termes des deux côtés.

# apt
sudo apt install nginx
sudo apt remove nginx
apt search nginx
apt show nginx

# dnf
sudo dnf install nginx
sudo dnf remove nginx
dnf search nginx
dnf info nginx

apt show est dnf info. C’est le seul verbe renommé du groupe, mais un comportement diffère et surprend souvent. dnf remove supprime également les dépendances dont plus rien n’a besoin, tandis que apt remove les laisse installées pour un prochain apt autoremove. Ainsi, la suppression d’un petit utilitaire sur Rocky Linux peut proposer de supprimer une douzaine de bibliothèques avec lui. Lisez la liste avant de confirmer.

Actualiser les métadonnées, vérifier ce qui est en attente et mettre à niveau.

# apt
sudo apt update
apt list --upgradable
sudo apt install --only-upgrade nginx
sudo apt upgrade

# dnf
sudo dnf makecache
dnf check-update
sudo dnf upgrade nginx
sudo dnf upgrade

apt update est obligatoire avec apt, car apt utilise les métadonnées présentes sur le disque et peut installer sans problème une version qui a quitté l’archive depuis des mois. dnf vérifie l’âge de son cache avant chaque transaction et télécharge lui-même les métadonnées à jour. sudo dnf makecache sert donc uniquement à forcer ce téléchargement immédiatement plutôt que lors de votre prochaine installation.

apt sépare la mise à niveau complète du système en deux commandes, contrairement à dnf. apt upgrade refuse de supprimer un paquet installé. Il s’arrête donc dès qu’une mise à jour nécessite d’en supprimer un. apt full-upgrade est la version autorisée à supprimer des paquets. dnf n’impose pas cette restriction. Cela signifie que dnf upgrade est l’équivalent de apt full-upgrade, et non de apt upgrade. dnf update est un ancien alias de la même commande et fonctionne toujours.

Un détail compte si vous automatisez ces commandes : dnf check-update se termine avec le code 100 lorsque des mises à jour sont en attente, et avec le code 0 lorsqu’il n’y en a aucune. apt list --upgradable se termine avec le code 0 dans les deux cas. Les scripts doivent donc analyser sa sortie.

Lister les paquets installés et déterminer quel paquet possède un fichier.

# apt
dpkg -l
dpkg -S /usr/sbin/nginx
dpkg -L nginx
apt-file search /usr/sbin/nginx

# dnf
dnf list --installed
rpm -qf /usr/sbin/nginx
rpm -ql nginx
dnf provides /usr/sbin/nginx

La dernière ligne de chaque bloc répond à une question différente de celles des lignes précédentes. dpkg -S et rpm -qf recherchent uniquement les paquets déjà installés. Ils répondent donc à la question « quel paquet a installé ce fichier ? ». apt-file search et dnf provides recherchent dans les dépôts. Ils répondent donc à la question « quel paquet installer pour obtenir ce fichier ? ». apt-file est un paquet distinct sur Ubuntu et nécessite sudo apt-file update avant sa première exécution. dnf provides ne nécessite rien de plus, mais sa première exécution peut être lente, car dnf télécharge les listes de fichiers des dépôts pour effectuer la recherche.

Pour lister les fichiers contenus dans un paquet que vous n’avez pas encore installé, utilisez dnf repoquery -l nginx. Avec apt, la commande correspondante est apt-file list nginx.

Supprimer automatiquement les dépendances inutilisées, nettoyer le cache et bloquer une version.

# apt
sudo apt autoremove
sudo apt clean
sudo apt-mark hold nginx
apt-mark showhold
sudo apt-mark unhold nginx

# dnf
sudo dnf autoremove
sudo dnf clean all
sudo dnf versionlock add nginx
dnf versionlock list
sudo dnf versionlock delete nginx

versionlock n’est pas installé par défaut sur Rocky Linux ou AlmaLinux. La première de ces lignes échoue donc avec No such command: versionlock sur une installation fraîche. Installez-le d’abord avec sudo dnf install python3-dnf-plugin-versionlock. apt ne nécessite rien de plus pour apt-mark hold, car un blocage de version est un état dpkg et non un plugin.

Ce qui ne correspond pas : ajouter un dépôt

C’est la partie qui pousse les administrateurs Ubuntu à chercher une commande qui n’existe pas. Il n’y a pas de add-apt-repository dans dnf et il n’existe pas d’archives personnelles de paquets (PPA). Un PPA est un service fourni par Launchpad, et Launchpad fait partie de l’infrastructure Ubuntu. Rien dans l’écosystème RPM n’en héberge.

À la place, dnf utilise un fichier texte simple par dépôt dans /etc/yum.repos.d/, avec l’extension .repo.

[docker-ce-stable]
name=Docker CE Stable
baseurl=https://download.docker.com/linux/centos/$releasever/$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg

$releasever et $basearch sont des variables dnf. dnf renseigne au moment de l’exécution le numéro de version majeure et l’architecture du processeur. Le même fichier fonctionne donc avec la version 9 et la version 10, ainsi qu’avec x86_64 et aarch64.

La plupart des éditeurs publient ce fichier et vous indiquent comment le récupérer. Les instructions officielles de Docker pour RHEL et ses dérivés se résument à deux commandes :

sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

La première ligne est nécessaire parce que config-manager est un plugin et ne fait pas partie de dnf lui-même. Si vous la sautez, la deuxième ligne échoue avec No such command: config-manager. Rien ne vous empêche de télécharger manuellement le même fichier .repo avec curl dans /etc/yum.repos.d/, avec un résultat identique. Installer Docker sur un VPS décrit l’opération équivalente côté Debian, où cette étape écrit une liste de sources et une clé de signature dans deux répertoires différents.

La différence de structure détermine l’endroit où chercher lorsqu’un dépôt pose problème. apt conserve les définitions dans /etc/apt/sources.list et /etc/apt/sources.list.d/, tandis que les clés de signature sont stockées séparément sous /etc/apt/keyrings/. dnf conserve tout dans /etc/yum.repos.d/, et la clé est une URL dans le fichier .repo : il n’y a donc qu’un fichier à lire et un fichier à supprimer. Les versions récentes d’apt se rapprochent de cette organisation avec le format deb822, qui utilise un fichier .sources par dépôt. Si vous avez rencontré l’erreur des sources dupliquées deb822 sur Ubuntu, vous avez déjà rencontré la partie apt de ce problème.

EPEL est le dépôt que supposent la plupart des guides

Extra Packages for Enterprise Linux (EPEL) est un projet Fedora qui compile des paquets Fedora pour RHEL et ses reconstructions. C’est ce qui se rapproche le plus d’un PPA universel, et un très grand nombre de tutoriels supposent qu’il est déjà activé. Si dnf install répond No match for argument pour un paquet présenté sur le site officiel du projet, EPEL est la première chose à vérifier.

Sur Rocky Linux et AlmaLinux :

sudo dnf config-manager --set-enabled crb
sudo dnf install epel-release
sudo dnf makecache

CRB signifie CodeReady Builder. Il s’agit d’un dépôt de bibliothèques fourni avec la distribution, mais qui n’est pas activé par défaut. La plupart des paquets EPEL dépendent d’un paquet qui s’y trouve. Activer EPEL sans CRB ne provoque donc pas d’échec immédiat. L’échec survient plus tard, au moment de l’installation, avec des dépendances non résolues vers un paquet dont vous n’avez jamais entendu parler. Activez d’abord CRB pour éviter cette catégorie d’erreur.

Sur RHEL, CRB est fourni par votre abonnement plutôt que par config-manager. Suivez donc les instructions EPEL de Red Hat pour cette étape. Fedora n’a besoin d’aucune de ces étapes, car son dépôt principal contient déjà les paquets rétroportés par EPEL. La politique d’EPEL consiste à ne jamais remplacer un paquet fourni par RHEL. L’ajout du dépôt ne modifie donc rien de ce qui est déjà installé sur votre serveur.

dnf history undo, ce qu’apt ne sait pas faire

dnf enregistre chaque transaction et peut en construire l’inverse.

sudo dnf history
sudo dnf history info 42
sudo dnf history undo 42

dnf history affiche la liste numérotée des transactions, avec la ligne de commande qui a lancé chacune d’elles. undo construit la transaction inverse : les paquets installés par cette transaction sont supprimés et les paquets mis à niveau reviennent à la version que vous aviez. C’est la fonctionnalité qui manque le plus aux utilisateurs d’apt après leur passage à dnf.

Cette fonction a des limites importantes, qu’il vaut mieux connaître avant de s’y fier. undo ne peut réinstaller une version de paquet que si celle-ci existe encore dans un dépôt activé. Si l’ancienne build a été retirée du miroir, l’annulation échoue avec une erreur indiquant que le paquet est introuvable. Le rollback s’arrête également au niveau de la base de données des paquets. Un fichier de configuration réécrit par la mise à niveau reste réécrit, et un schéma de base de données migré par un service lors de son premier démarrage reste migré. dnf remet les fichiers en place. Il ne restaure pas vos données.

apt n’a pas d’équivalent. /var/log/apt/history.log enregistre précisément ce qui s’est passé, y compris la ligne de commande, mais consulter un journal ne permet pas d’annuler l’opération. Avec apt, la récupération est manuelle : exécutez apt list -a nginx pour voir quelles versions sont encore disponibles dans l’archive, puis sudo apt install nginx=<exact version string> pour en figer une, et ajoutez sudo apt-mark hold nginx afin que la prochaine mise à niveau n’annule pas votre correction.

Les groupes de paquets n’ont pas d’équivalent avec apt

dnf peut installer un ensemble nommé de paquets en une seule commande.

dnf group list
dnf group info "Development Tools"
sudo dnf group install "Development Tools"

Les anciens guides écrivent dnf groupinstall "Development Tools". Cet alias fonctionne avec dnf 4, mais il a disparu dans dnf 5. La forme en deux mots, dnf group install, est donc la seule qui fonctionne partout. Utilisez-la et n’y pensez plus.

apt ne prend pas en charge les groupes. L’équivalent le plus proche dans Debian est un métapaquet : un paquet autrement vide dont le seul contenu est une liste de dépendances, comme build-essential. La différence pratique apparaît lors de la suppression : supprimer un métapaquet laisse ses dépendances installées jusqu’à l’exécution de apt autoremove, tandis que dnf group remove supprime les paquets du groupe dans la même transaction.

mises à jour sans intervention et dnf-automatic

Les deux familles permettent d’installer les mises à jour sans qu’un utilisateur soit connecté. Elles n’ont en commun que cet objectif.

Sur Ubuntu et Debian, le paquet est unattended-upgrades. Il est configuré dans /etc/apt/apt.conf.d/50unattended-upgrades, où vous indiquez les origines depuis lesquelles il est autorisé à télécharger les paquets. Configurer les mises à jour sans intervention sur Ubuntu présente ce fichier de configuration ainsi que la question du redémarrage qui l’accompagne.

Sur Rocky Linux, AlmaLinux et Fedora, le paquet est dnf-automatic. Le timer systemd que vous activez détermine le comportement.

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer
systemctl list-timers 'dnf-automatic*'

dnf-automatic-install.timer télécharge et applique les mises à jour. dnf-automatic-download.timer les télécharge puis s’arrête, en vous laissant effectuer l’installation. dnf-automatic-notifyonly.timer se contente de générer des rapports. Chacune de ces unités remplace le paramètre apply_updates dans /etc/dnf/automatic.conf. Le timer que vous choisissez compte donc davantage que le contenu du fichier de configuration. L’installation d’une mise à jour ne redémarre pas les processus qui exécutent encore l’ancien code. Il est donc utile de vérifier quelles mises à jour nécessitent un redémarrage et lesquelles nécessitent seulement le redémarrage d’un service avant de considérer le serveur comme corrigé.

Pour limiter les mises à jour aux correctifs de sécurité, définissez upgrade_type = security dans /etc/dnf/automatic.conf. Ce filtre dépend de la publication des errata de sécurité par vos dépôts. Vérifiez donc d’abord avec dnf updateinfo list security. Un résultat vide sur un serveur qui a des mises à jour en attente signifie que ces métadonnées sont absentes. security n’installerait alors absolument rien.

Sur Fedora, dnf 5 a renommé l’unité. Il s’agit de dnf5-automatic.timer, qui lit le même /etc/dnf/automatic.conf.

yum est-il toujours une vraie commande ?

Oui, mais elle ne fait rien par elle-même. Sur Rocky Linux, AlmaLinux et CentOS Stream, /usr/bin/yum est un lien symbolique qui pointe vers dnf. Vérifiez le vôtre :

ls -l /usr/bin/yum
dnf --version

L’ancienne syntaxe de yum reste présente dans les tutoriels, car elle continue généralement de fonctionner telle quelle. yum install, yum remove et yum update fonctionnent tous. Une habitude doit toutefois être abandonnée : yum-config-manager existe encore comme binaire distinct sur les systèmes utilisant dnf 4, mais dnf config-manager est la syntaxe employée par la documentation actuelle. C’est aussi celle qui continuera de fonctionner lorsque le serveur passera à dnf 5.

dnf 4 et dnf 5 : vérifiez avant de copier une commande

dnf 5 est une réécriture complète et la syntaxe de plusieurs commandes a changé. Fedora 41 et les versions ultérieures le fournissent sous la forme de dnf. Les distributions Enterprise compatibles ont adopté ce changement plus lentement. Ne déduisez donc pas la version à partir du nom de la distribution. Exécutez dnf --version sur votre propre serveur et lisez la première ligne. Ce numéro détermine la syntaxe à utiliser ci-dessous.

L’exemple le plus clair concerne Docker, qui publie une commande de dépôt différente pour chaque version. Sur RHEL et ses distributions compatibles, avec dnf 4 :

sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

Sur Fedora, avec dnf 5 :

sudo dnf config-manager addrepo --from-repofile https://download.docker.com/linux/fedora/docker-ce.repo

Même éditeur, même objectif, syntaxe différente. dnf 5 a transformé config-manager en outil piloté par des sous-commandes. L’ancien indicateur --add-repo n’est donc pas accepté et vous obtenez une erreur d’utilisation au lieu d’un dépôt. L’autre différence que vous rencontrerez concerne l’activation d’un dépôt : dnf config-manager --set-enabled crb avec dnf 4 devient dnf config-manager setopt crb.enabled=1 avec dnf 5.

Le choix qui compte réellement

Choisir une distribution serveur uniquement en fonction du gestionnaire de paquets n’est pas le bon critère. dnf et apt font le même travail, et leur vocabulaire s’apprend en une après-midi. Ce qui change votre année, c’est le modèle de publication utilisé par le dépôt. Fedora évolue rapidement et une version donnée cesse de recevoir des mises à jour environ treize mois après sa sortie. C’est acceptable pour un poste de travail, mais problématique pour un serveur que vous ne voulez pas reconstruire. Rocky Linux et AlmaLinux suivent RHEL. Vous bénéficiez donc d’une période de support de dix ans et de versions de paquets qui restent volontairement stables. Ubuntu propose les deux modèles, et la différence entre les versions Ubuntu LTS et les versions intermédiaires sur un serveur correspond au même choix dans l’écosystème apt.

En août 2026, toutes ces distributions sont des images VPS courantes. Choisissez la période de support dont vous avez besoin, puis apprenez les dix commandes ci-dessus.

FAQ

Quel est l’équivalent de apt update avec dnf ?

Vous n’avez aucune commande à exécuter. Avant chaque transaction, dnf vérifie depuis combien de temps ses métadonnées sont mises en cache et télécharge une copie récente lorsqu’elles ont expiré. Ainsi, dnf install sur un serveur auquel vous n’avez pas touché depuis un mois voit toujours les paquets actuels. sudo dnf makecache existe et force effectivement ce téléchargement, mais son intérêt réel est de déplacer l’attente à un moment que vous choisissez plutôt que de la subir lors de votre prochaine installation. La commande qui répond à la question « qu’est-ce qui m’attend ? » est dnf check-update. Elle correspond à apt list --upgradable et se termine avec le code d’état 100 lorsque des mises à jour sont disponibles.

Existe-t-il un équivalent des PPA sur Rocky Linux ou Fedora ?

Non. Les archives personnelles de paquets sont un service Launchpad, et Launchpad fait partie de l’infrastructure Ubuntu. add-apt-repository n’a donc rien à traduire. L’équivalent RPM est un fichier .repo dans /etc/yum.repos.d/, qui contient un nom, un baseurl et un gpgkey. Les éditeurs publient ce fichier pour vous, et sudo dnf config-manager --add-repo <url> avec dnf 4, ou sudo dnf config-manager addrepo --from-repofile <url> avec dnf 5, le télécharge à l’emplacement approprié. Pour les logiciels supplémentaires courants, la réponse est généralement EPEL, que vous activez avec sudo dnf config-manager --set-enabled crb, puis sudo dnf install epel-release.

Puis-je annuler une mise à niveau dnf qui a cassé mon serveur ?

Oui, dans certaines limites. Exécutez sudo dnf history pour trouver le numéro de transaction, sudo dnf history info <id> pour voir exactement ce qu’elle a modifié, puis sudo dnf history undo <id>. L’annulation échoue si l’ancienne version du paquet n’est plus présente dans aucun dépôt activé, car dnf n’a alors rien à réinstaller. Elle n’annule également que les modifications apportées aux paquets. Un fichier de configuration réécrit par la mise à niveau, ou une base de données migrée par un service lors de son premier démarrage, reste inchangé. apt ne possède aucune commande équivalente : il conserve uniquement l’historique dans /var/log/apt/history.log.

yum fonctionne-t-il toujours sur Rocky Linux et AlmaLinux ?

Oui, car /usr/bin/yum est un lien symbolique vers dnf. Vérifiez-le sur votre propre machine avec ls -l /usr/bin/yum. Saisir yum install httpd exécute dnf, de sorte que les anciens tutoriels fonctionnent encore pour la plupart. Écrivez les nouveaux scripts et la nouvelle documentation avec dnf, car le nom yum n’est conservé que pour la compatibilité. Préférez aussi dnf config-manager à l’ancien binaire yum-config-manager.

Pourquoi dnf remove veut-il supprimer autant de paquets ?

Parce que dnf supprime, dans le cadre de la même transaction, les dépendances dont aucun autre paquet n’a besoin, tandis que apt remove les laisse installées jusqu’à l’exécution séparée de apt autoremove. Ainsi, une suppression qui semble limitée sur Ubuntu peut afficher une longue liste sur Rocky Linux. Cette liste est généralement correcte, mais lisez-la avant de confirmer. Si elle contient un paquet que vous souhaitez conserver, installez-le explicitement au préalable afin que dnf l’enregistre comme explicitement requis.