Rocky Linux / DNF : installer, mettre à jour et supprimer des paquets

DNF est l’outil de Rocky Linux pour rechercher, installer, mettre à jour et supprimer des paquets RPM en tenant compte de leurs dépendances. Avant de valider une transaction, vérifiez les versions, les dépôts et toutes les suppressions proposées ; l’historique DNF aide à comprendre les changements, mais ne remplace pas une sauvegarde.

Vérifier la version et préparer une intervention

DNF signifie Dandified YUM. Un paquet RPM contient des fichiers logiciels et des informations permettant leur installation ; DNF choisit les paquets et résout leurs dépendances à partir des dépôts configurés. Commencez par identifier votre système et l’implémentation disponible :

cat /etc/rocky-release
dnf --version
dnf --help

La forme générale est dnf [options] commande [cible]. Les exemples utilisent les commandes de DNF classique ; vérifiez l’aide installée si une sous-commande diffère dans votre environnement. Les consultations se font généralement sans privilèges. Installer, supprimer ou mettre à jour des paquets nécessite un compte autorisé à utiliser sudo.

Disposez d’un accès aux dépôts, d’espace disque et, pour un serveur, d’une sauvegarde des données et configurations utiles. Les exemples d’installation, de réinstallation et de suppression ci-dessous correspondent à des besoins différents : ils ne forment pas un script à exécuter intégralement. Le guide DNF de Rocky Linux présente le gestionnaire dans le contexte de la distribution.

Trouver un paquet ou le fournisseur d’un fichier

Rechercher un nom puis examiner les informations

dnf search nginx
dnf info nginx
dnf search --all nginx

Avec DNF classique, search cherche par défaut dans les noms et résumés. --all étend notamment la recherche aux descriptions et aux URL ; avec plusieurs mots, il change aussi leur combinaison, d’une correspondance avec tous les mots à une correspondance avec au moins un mot. Un résultat de recherche n’est donc pas une garantie que le paquet remplit votre besoin.

Dans info, comparez nom, architecture, version et dépôt. Plusieurs résultats peuvent correspondre à des architectures ou versions différentes. Vérifiez ensuite la documentation du logiciel avant de retenir le paquet.

Partir d’une commande ou d’un chemin

dnf provides '*/semanage'
dnf provides /usr/bin/rsync

provides recherche les paquets qui fournissent la cible. Le motif entre guillemets permet de chercher semanage sans laisser le shell développer * dans le répertoire courant. Cette recherche exploite les métadonnées des dépôts ; elle ne signifie pas que le paquet est installé. Pour identifier le propriétaire d’un fichier déjà présent et consulter l’inventaire local, utilisez aussi le guide des paquets installés avec DNF et RPM.

Installer, vérifier ou réinstaller

Avant une première installation de Nginx, vous pouvez examiner la proposition sans valider la transaction RPM :

sudo dnf install nginx --assumeno

DNF peut contacter les dépôts et écrire des métadonnées en cache. --assumeno répond non aux confirmations : ce n’est pas une exécution sans aucun accès réseau ou écriture de cache. Lisez la liste des paquets, les versions, la taille et les dépôts. Si le projet correspond au besoin, relancez sans cette option et confirmez après lecture :

sudo dnf install nginx
rpm -q nginx

Une sortie de rpm -q identifiant le paquet confirme son enregistrement dans la base RPM ; elle ne prouve pas que le serveur web est démarré ou correctement configuré. Testez le logiciel et son service selon l’usage prévu. L’installation d’un paquet ne dispense pas de configurer les accès réseau et les données applicatives.

Pour un paquet déjà installé dont les fichiers fournis doivent être réinstallés :

sudo dnf reinstall nginx

Le même RPM doit encore être disponible. La réinstallation suit les règles du paquet pour les fichiers de configuration : elle n’est pas un bouton de remise à zéro de tous les réglages locaux. Conservez vos configurations et examinez les éventuels fichiers .rpmnew ou .rpmsave avant de décider quoi fusionner.

Pour un fichier RPM local fourni par un éditeur vérifié, adaptez ce chemin à un fichier réellement téléchargé :

sudo dnf install ./example-package.rpm

DNF peut obtenir les dépendances dans les dépôts activés. Le chemin local ne garantit pas l’authenticité : vérifiez l’origine, la signature et la clé du fournisseur. Le contrôle des RPM locaux dépend notamment de localpkg_gpgcheck et de la politique RPM ; il ne faut pas supposer qu’un fichier local reçoit exactement les contrôles d’un dépôt. La référence de configuration DNF distingue ces réglages.

Consulter et appliquer les mises à jour

Interpréter la recherche et son code de retour

dnf check-update
dnf updateinfo list

check-update renvoie 100 si des mises à jour sont disponibles, 0 s’il n’en trouve pas et 1 en cas d’erreur. Dans un script, traitez 100 comme un résultat attendu. Une version annoncée n’est pas forcément installable lors de la transaction suivante : les dépendances et les dépôts disponibles comptent aussi.

updateinfo consulte les avis fournis par les dépôts. Une liste vide ne démontre pas, à elle seule, l’absence de vulnérabilité : les métadonnées d’avis doivent être disponibles et couvrir les paquets concernés.

Choisir l’étendue puis contrôler le résultat

Pour examiner une mise à jour générale, puis l’appliquer après préparation :

sudo dnf upgrade --assumeno
sudo dnf upgrade

Pour cibler un paquet particulier, utilisez à la place sudo dnf upgrade openssl. Les dépendances peuvent entraîner d’autres changements : la cible ne constitue pas une limite stricte au nombre de paquets modifiés. Ne lancez pas simultanément plusieurs transactions.

Après l’opération, vérifiez le message final, l’historique, les versions installées et le fonctionnement des services. Un processus peut encore utiliser une ancienne bibliothèque jusqu’à son redémarrage ; un nouveau noyau doit être démarré pour devenir le noyau actif. Planifiez les redémarrages nécessaires et vérifiez les applications, plutôt que de considérer le téléchargement comme la fin de l’intervention.

Supprimer un paquet sans oublier ses dépendances

Commencez par examiner toute la proposition de suppression :

sudo dnf remove nginx --assumeno

Elle peut inclure des paquets qui dépendent de la cible et, selon la configuration, des dépendances devenues inutiles. Si un service ou un outil nécessaire figure dans la liste, refusez et analysez la relation. Quand la suppression est réellement voulue, sauvegardez les données utiles puis relancez :

sudo dnf remove nginx

La suppression du paquet n’équivaut pas à l’effacement contrôlé de toutes ses données ou configurations. À l’inverse, une réinstallation ne garantit pas leur restauration : identifiez les fichiers que le paquet et l’application gèrent.

Pour examiner les dépendances que DNF considère comme devenues inutiles :

sudo dnf autoremove --assumeno

Cette sélection dépend des raisons d’installation enregistrées. Un logiciel utilisé manuellement peut encore avoir besoin d’un paquet que DNF juge supprimable : relisez les candidats avant de lancer sudo dnf autoremove. Ne nettoyez pas une liste en masse uniquement parce qu’elle est longue.

Lister les paquets et comprendre les dépôts

Distinguer installé, disponible et à mettre à jour

dnf list --installed
dnf list --available
dnf list --upgrades

La première liste décrit les paquets installés. Les deux autres dépendent notamment des dépôts et du cache consultés. Une absence peut venir d’un dépôt désactivé, d’une architecture différente ou d’un filtrage de paquets ; elle ne prouve pas que le logiciel n’existe pas pour Rocky Linux.

Choisir un dépôt pour une seule commande

dnf repolist
dnf repolist --all
dnf repository-packages appstream list --available

appstream est un exemple d’identifiant : utilisez un identifiant réellement affiché sur votre machine. Un nom de dépôt lisible et son identifiant technique peuvent différer. Avant d’ajouter une source, vérifiez fournisseur, version de Rocky, architecture, clé de signature et risque de remplacement de paquets de la distribution.

Pour modifier temporairement la sélection, remplacez les noms d’exemple par un dépôt déjà configuré et un paquet vérifié :

sudo dnf --disablerepo='example-repo' upgrade --assumeno
sudo dnf --enablerepo='example-repo' install package-name --assumeno

Ces options concernent cette invocation ; elles ne modifient pas le réglage persistant du fichier .repo. Activer un dépôt ne désactive pas les autres. Une fois la proposition comprise, retirez --assumeno si vous souhaitez exécuter la transaction avec la même sélection. Si elle change entre-temps, relisez le nouveau résultat avant confirmation.

Examiner l’historique et les limites d’un retour arrière

dnf history
dnf history info 42

Remplacez 42 par l’identifiant réel de la transaction. Examinez sa date, sa commande et l’ensemble des paquets modifiés ; ne choisissez pas un numéro trouvé dans un exemple. Une interruption ou une modification de la base RPM en dehors de DNF peut compliquer l’interprétation.

Pour examiner l’opération inverse sans l’exécuter :

sudo dnf history undo 42 --assumeno

undo porte sur une transaction, tandis que rollback vise les transactions postérieures à un point choisi. Ni l’un ni l’autre ne restaure une base de données applicative ou une configuration sauvegardée ailleurs. Les anciennes versions doivent être disponibles et les dépendances compatibles. Une rétrogradation après migration de données peut être inutilisable, même si le gestionnaire de paquets l’accepte.

Utilisez sudo dnf history undo 42 seulement après avoir évalué la proposition et le plan de récupération de l’application. Pour un changement de composants essentiels, préférez la procédure de restauration validée pour votre système à une annulation improvisée. Les options précises et codes de retour sont détaillés dans la référence officielle des commandes DNF.

Gérer le cache et diagnostiquer une erreur

Les caches peuvent dépendre de l’utilisateur ; les exemples avec sudo visent celui utilisé pour les opérations administratives. Pour forcer une actualisation des métadonnées avant une recherche, utilisez par exemple sudo dnf --refresh makecache.

Avant un nettoyage général, lisez l’erreur. Contrôlez la connectivité, le DNS, l’heure du système, les URL de dépôt, l’espace disque et une éventuelle transaction déjà active. Une erreur de signature demande de vérifier la provenance du paquet et la clé attendue ; supprimer le cache ne justifie pas de désactiver les contrôles de signature.

Retrouver les commandes courantes

Remplacez les cibles génériques par les noms vérifiés. Sur un serveur important, gardez un inventaire avant et après, contrôlez la transaction complète et testez les services concernés. Une confirmation automatique avec -y ne convient qu’à une procédure dont le périmètre et les effets sont déjà maîtrisés.