DNF : choisir son gestionnaire de paquets sans se raconter d'histoires

C'est tout ce que la plupart des gens demandent à un gestionnaire de paquets. Une commande, une réponse, pas de surprise. Et pourtant, derrière ce mot de trois lettres se cache une décision que tu prends sans le savoir à chaque fois que tu installes une distribution RPM.

DNF, pour Dandified YUM, est le gestionnaire de paquets par défaut des distributions qui utilisent le format RPM. Fedora, RHEL, Rocky Linux, AlmaLinux, CentOS Stream. Si tu es sur l'une de ces familles, tu tapes `dnf` tous les jours, même si tu ne t'en rends pas compte.

Ce que ça fait, concrètement : chercher, installer, supprimer, mettre à jour des paquets. Et surtout, résoudre les dépendances à ta place. Tu veux installer un programme, il tire automatiquement tout ce dont ce programme a besoin. Sans que tu aies à chercher manuellement les vingt bibliothèques qui vont avec.

C'est là que tout se joue.

Ce que YUM faisait, et pourquoi ça a fini par coincer

YUM, Yellow-Dog Updater Modified, a rendu service pendant des années. Il était là, il faisait le travail, et personne ne se plaignait vraiment.

Sauf que YUM était lent. Vraiment lent, sur les grosses résolutions de dépendances. Et parfois imprécis : il pouvait te proposer des solutions bancales, voire échouer là où un humain aurait trouvé la sortie.

Aleš Kozumplík, chez Red Hat, a documenté ces problèmes dès 2011. Pas seulement dans YUM, aussi dans Anaconda, l'installateur de Fedora. Le constat était simple : l'architecture derrière YUM ne tenait plus la charge.

Le projet DNF a été forké de YUM en janvier 2012. L'objectif n'était pas de tout réécrire pour le plaisir, mais de repartir sur une base plus légère, plus maintenable, et surtout plus rapide sur le point qui fâchait : la résolution de dépendances.

Fedora 18, en janvier 2013, a embarqué DNF comme option expérimentale. Pas par défaut. Juste là, pour ceux qui voulaient tester. C'est la période où on découvre les vrais bugs, celle qu'on ne voit jamais dans les annonces.

Puis Fedora 22, en mai 2015, a basculé. DNF est devenu le gestionnaire par défaut, validé par le Fedora Engineering Steering Committee. À partir de là, la question n'était plus « est-ce que DNF remplace YUM », mais « quand est-ce que le reste suit ».

Le vrai changement n'est pas dans la commande

`dnf install` ressemble à `yum install`. C'est volontaire, et c'est confortable. Tu ne réapprends pas ta syntaxe.

Ce qui change, c'est sous le capot. DNF s'appuie sur libsolv, une bibliothèque de résolution conçue pour traiter des graphes de dépendances complexes rapidement. Par-dessus, hawkey fournit une API propre pour les fonctions de gestion de paquets.

Traduction pratique : quand tu demandes une mise à jour sur un système avec des centaines de paquets et des contraintes croisées, DNF trouve une solution cohérente là où YUM tâtonnait. Et il le fait plus vite.

Le revers, c'est que cette mécanique a un coût en complexité. libsolv et hawkey ne sont pas des briques que tu vas debugger à la main un dimanche soir. Si quelque chose casse à ce niveau, tu remontes des rapports de bug, tu ne bricoles pas.

DNF travaille avec le format RPM, qui contient les fichiers du programme, mais aussi les métadonnées : dépendances, versions, scripts d'installation. C'est cette couche de métadonnées qui permet à DNF de garantir la cohérence du système. Sans elle, il n'y a pas de résolution possible.

Fedora d'abord, le reste ensuite

Fedora sert de terrain d'essai. C'est son rôle historique : tester des technologies que RHEL adoptera plus tard, une fois qu'elles ont prouvé leur solidité.

DNF a suivi ce chemin. RHEL 8 l'a adopté comme standard. Rocky Linux et AlmaLinux, les alternatives gratuites et binairement compatibles avec RHEL, l'ont repris aussi. Pas par préférence idéologique, par nécessité de compatibilité : si tu remplaces RHEL par Rocky, tu ne veux pas réapprendre ton gestionnaire de paquets.

C'est ce qui fait la force tranquille de DNF. Il n'a pas gagné parce qu'il était le plus élégant. Il a gagné parce qu'il est devenu le dénominateur commun d'un écosystème entier.

Et ça, pour un administrateur qui gère un parc mixte, ça vaut plus que n'importe quelle fonctionnalité isolée.

Là où le choix se corse

Si tu es sur Fedora, RHEL, Rocky ou AlmaLinux, tu n'as pas vraiment de choix. DNF est là, il fonctionne, et remplacer le gestionnaire de paquets d'une distribution RPM est une aventure que peu de gens veulent tenter.

Si tu viens de Debian ou Ubuntu, tu connais `apt`. Et honnêtement, `apt` fait très bien le travail. La différence entre `apt` et `dnf` n'est pas une question de qualité, c'est une question d'écosystème. Les paquets RPM et DEB ne se mélangent pas, et les deux communautés ont construit leurs outils autour de leurs formats respectifs.

Là où DNF montre ses limites, c'est dans sa courbe d'apprentissage quand tu veux aller au-delà du basique. Les options de `dnf` sont nombreuses, la configuration par modules dans RHEL 8 et suivants ajoute une couche, et les messages d'erreur de résolution peuvent être abrupts quand tu tombes sur un conflit réel.

Ce n'est pas un défaut de conception. C'est le prix d'un outil qui gère des systèmes d'entreprise où une mauvaise résolution peut casser une production.

Ce que tu gagnes, ce que tu paies

Tu gagnes la rapidité sur les résolutions complexes. Tu gagnes la fiabilité sur les mises à jour de masse. Tu gagnes un outil maintenu activement, avec une base de code moderne.

Tu paies en complexité quand tu veux comprendre ce qui se passe sous le capot. Tu paies aussi en dépendance : DNF n'existe pas tout seul, il s'appuie sur libsolv, hawkey, RPM, et l'ensemble doit rester cohérent.

Et tu paies une dernière chose, plus discrète : la documentation. Elle est bonne, mais elle suppose que tu sais déjà ce que tu cherches. Pour un débutant qui veut juste installer Firefox, ça passe. Pour quelqu'un qui doit diagnostiquer un conflit de dépendances sur un serveur de production, il faut creuser.

Le point qui décide

DNF n'est pas meilleur que `apt` dans l'absolu, et `apt` n'est pas meilleur que DNF. Ils résolvent le même problème dans deux écosystèmes différents, avec des philosophies proches et des contraintes distinctes.

Ce qui décide, ce n'est pas la qualité technique de l'outil. C'est la distribution que tu as choisie, et l'écosystème dans lequel tu dois vivre.

Si tu es sur RPM, DNF est là et il fait le travail. Si tu es sur DEB, `apt` est là et il fait le travail. La vraie question n'est pas « lequel est le meilleur », c'est « lequel correspond à l'infrastructure que tu dois maintenir ».

Le reste, c'est de la préférence personnelle déguisée en argument technique.