Linux / Commande dnf : gérer les paquets et distinguer DNF 4 de DNF5

dnf cherche, installe, retire et met à niveau les paquets de distributions utilisant RPM, notamment dans les familles Fedora et RHEL. Il résout les dépendances à partir des dépôts activés. Vérifiez d’abord si votre commande correspond à DNF 4 ou à DNF5 : les noms de sous-commandes et certaines options diffèrent.

Identifier la version et les dépôts utilisés

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

Les exemples utilisant dnf ci-dessous suivent DNF 4 ; les formes DNF5 sont indiquées séparément lorsque cela compte. Selon la distribution et sa version, dnf peut lancer une implémentation différente. Consultez man dnf ou man dnf5 et l’aide locale avant de reprendre une commande trouvée pour un autre système.

dnf [OPTIONS] COMMANDE [ARGUMENTS ...]

Commencez par consulter les dépôts activés. Cette lecture ne les active ni ne les désactive :

dnf repolist

Dans DNF5, la forme documentée est dnf5 repo list. Les identifiants et les noms permettent de repérer une source absente ou inattendue. Un dépôt activé n’est pas nécessairement joignable à cet instant ; les règles de cache et la politique de disponibilité peuvent aussi influencer la consultation.

DNF utilise des métadonnées locales et peut les rafraîchir selon la commande et leur expiration. Une requête sans changement de paquets peut donc contacter un dépôt ou écrire un cache. Ne confondez pas consultation des paquets et absence totale d’activité réseau ou de fichiers temporaires.

Chercher un paquet et distinguer disponible et installé

dnf search nginx
dnf info nginx
dnf info bash

nginx est un exemple de paquet recherché ; bash permet d’observer les informations d’un composant courant. search trouve des noms et descriptions correspondants. info présente notamment la version, la révision, l’architecture, le dépôt et la description, selon les paquets connus.

Lisez les sections relatives aux paquets installés et disponibles au lieu de supposer que la première version affichée est celle installée. Un résultat de recherche ne prouve pas l’installation. Les valeurs dépendent de la distribution, des dépôts, de l’architecture et du moment : un exemple x86_64 ne s’applique pas à toutes les machines.

Si le paquet attendu n’apparaît pas, vérifiez son nom, les dépôts et les erreurs de métadonnées avant d’ajouter une source extérieure. Une version plus récente en amont n’est pas forcément proposée ni compatible avec les règles de votre distribution.

Examiner une transaction puis installer

Pour préparer une installation de nginx sans confirmer les changements de paquets :

sudo dnf --assumeno install nginx

--assumeno répond non aux questions. Il permet de lire le plan avant de refuser son application ; ce n’est pas un simulateur isolé de tout effet, car la résolution peut utiliser le réseau et le cache. Examinez ajouts, remplacements, versions, dépôts et éventuelles suppressions. Une fin liée au refus attendu n’est pas une installation réussie.

Si le logiciel, les sources et le plan conviennent à cette machine :

sudo dnf install nginx

Relisez le récapitulatif avant de confirmer. Ne remplacez pas cette décision par -y sans politique de changement définie. Les scripts des paquets peuvent agir sur le système ; l’état d’un service ne doit pas être déduit de la seule réussite de la transaction.

Après réussite, consultez l’état enregistré et l’historique :

dnf info --installed nginx
dnf history list
dnf history info

info --installed limite la lecture aux paquets installés. L’historique permet de retrouver les actions et la transaction récente, lorsqu’elles ont été enregistrées. Il n’est pas un test de réponse du serveur web ni un journal de toutes les modifications manuelles des fichiers.

Pour un RPM local fiable et compatible, DNF 4 accepte aussi sudo dnf install ./example.rpm. example.rpm est un nom à remplacer par un fichier réellement obtenu et vérifié. DNF peut chercher les dépendances disponibles dans les dépôts, contrairement à une installation directe avec rpm ; il ne garantit pas pour autant la fiabilité d’un fichier local ou sa compatibilité avec une autre version de distribution.

Vérifier les mises à jour et traiter correctement le code 100

dnf check-update

Cette commande DNF 4 recherche les mises à jour sans les installer. Son code 100 signifie que des mises à jour sont disponibles ; 0 signifie qu’aucune n’a été trouvée. Une erreur doit être traitée séparément. Ne classez donc pas tous les codes non nuls comme un échec de dépôt.

Dans Bash, la branche suivante conserve cette distinction, y compris si votre script utilise un arrêt sur erreur ailleurs :

if dnf check-update; then
    printf 'Aucune mise a jour proposee.\n'
else
    result=$?
    case "$result" in
        100) printf 'Des mises a jour sont disponibles.\n' ;;
        *) printf 'Echec de verification, code %s\n' "$result" >&2
           exit "$result" ;;
    esac
fi

Avec DNF5, utilisez la commande documentée dnf5 check-upgrade dans cette condition ; les codes 0 et 100 gardent ces significations. Vérifiez les autres diagnostics dans la documentation de la version utilisée. Le manuel DNF5 de check-upgrade décrit ce résultat.

Une version indiquée par le contrôle n’est pas une promesse qu’upgrade l’installera : la transaction doit encore satisfaire les dépendances et les règles de sélection. Pour appliquer les mises à niveau avec DNF 4, après examen du plan et préparation de l’intervention :

sudo dnf upgrade

Prévoyez les interruptions et les redémarrages éventuellement nécessaires, notamment après mise à jour de composants utilisés ou du noyau. Mettre à jour les fichiers d’un paquet ne signifie pas que tous les processus utilisent déjà les nouvelles versions.

Reconnaître les différences de commandes et les retraits

Ces formes désignent explicitement l’implémentation ; des alias de compatibilité peuvent exister mais il ne faut pas en déduire que toutes les options ou tous les plugins sont interchangeables. Consultez la référence des commandes DNF 4 ou la référence DNF5 selon le programme installé.

remove peut retirer aussi des paquets dépendants ou devenus inutiles selon la configuration : lisez la transaction complète. --allowerasing autorise des suppressions pour résoudre un conflit ; ce n’est pas un correctif anodin à ajouter systématiquement. Gardez les vérifications de signatures et examinez les sources au lieu de contourner une erreur de confiance.

Enfin, les opérations d’annulation de l’historique sont des changements de paquets, pas une restauration complète des données ou de l’état applicatif. Elles dépendent notamment des versions encore disponibles et de l’état courant. Conservez une sauvegarde adaptée avant les changements importants plutôt que de considérer history comme un remplacement.