Waarom er twee versies zijn
Je typt `yum install nginx` en krijgt een melding dat yum verouderd is. Dat overkomt iedereen die na 2015 een RPM-distributie opende.
DNF staat voor Dandified YUM. Het is de pakketbeheerder die je tegenkomt op Fedora, RHEL 8 en later, Rocky Linux, AlmaLinux en Oracle Linux. Als je van Debian of Ubuntu komt, is dit je eerste kennismaking met de RPM-kant van de Linux-wereld. En met een gereedschap dat zich anders gedraagt dan apt.
De vraag is niet of je DNF moet gebruiken. Op die distributies is er geen redelijk alternatief. De vraag is welke versie je voor je hebt, en wat dat voor je scripts betekent.
Waarom er twee versies zijn
Tot voor kort was er één DNF. Sinds Fedora 41, uitgebracht in oktober 2024, is dat niet meer zo. Fedora gebruikt standaard DNF5, een volledig herschreven implementatie. RHEL 9 en de daarvan afgeleide distributies draaien nog op de oudere DNF, de versie die sinds Fedora 22 in 2015 de standaard werd en in 2019 zijn weg vond naar RHEL 8.Dat verschil merk je. Niet in de commando's die je dagelijks typt, want die zijn grotendeels gelijk gebleven. Wel in de snelheid, het geheugengebruik en de foutmeldingen. DNF5 start sneller op en geeft duidelijkere klachten als een repository niet bereikbaar is. Op een server met weinig geheugen is dat geen luxe.
De prijs van die sprong: de plugin-architectuur is anders. Als je een oudere DNF-plugin gebruikt, bijvoorbeeld voor versievergrendeling of een specifieke repository-integratie, kan die onder DNF5 niet meer werken. Voor de meeste servers is dat geen probleem. Voor systemen met maatwerk wel.
Wat je dagelijks typt
De commando's die je het vaakst nodig hebt, zijn in beide versies hetzelfde.```bash sudo dnf install nginx sudo dnf update sudo dnf remove nginx sudo dnf search nginx sudo dnf info nginx ```
Dat is de basis. `install`, `update`, `remove`, `search`, `info`. Wie van yum komt, herkent alles. De commando's zijn bewust compatibel gehouden, zodat bestaande scripts bleven werken toen Fedora in 2015 overstapte.
Wat DNF toevoegt ten opzichte van yum zit in de afhankelijkheidsresolutie. Waar yum soms vastliep of een onverwachte keuze maakte, lost DNF dat consistenter op. In de praktijk merk je dat het minst bij een simpele installatie en het meest bij het bijwerken van een systeem dat maanden heeft stilgestaan.
De geschiedenis die je echt gebruikt
DNF heeft een transactielog. Elke installatie, update of verwijdering wordt vastgelegd. Dat is geen administratieve franje.```bash sudo dnf history ```
Dat geeft je een genummerde lijst van alles wat er op het systeem is gebeurd. Je ziet wanneer, wat, en welke gebruiker het deed. Heb je een update geïnstalleerd die iets brak, dan kun je terug.
```bash sudo dnf history undo 42 ```
Waarbij 42 het transactienummer is. DNF draait dan de wijzigingen van die transactie terug. Dit werkt niet altijd feilloos. Als een pakket inmiddels van de repository is verdwenen, kan DNF de rollback niet volledig uitvoeren. Maar voor het gros van de gevallen waarin een update iets omlegt, is dit je redmiddel.
Op een server die je niet elke dag aanraakt, is dit het verschil tussen een kwartier zoeken en een half uur wachten tot iemand terugbelt. De geschiedenis is lokaal. Er is geen centrale logging, geen dashboard. Je moet het zelf opvragen.
Repositories, daar zit het echte werk
Een DNF-systeem is zo goed als de repositories die erin staan. Standaard krijg je de officiële repositories van je distributie mee. Voor extra software voeg je repositories toe via een `.repo`-bestand in `/etc/yum.repos.d/`.```bash sudo dnf config-manager --add-repo https://example.com/repo.repo ```
In DNF5 is dat commando veranderd. Daar gebruik je:
```bash sudo dnf config-manager addrepo --from-repofile=https://example.com/repo.repo ```
Kleine verandering, groot gevolg voor je documentatie en scripts. Als je een handleiding volgt die `--add-repo` gebruikt op Fedora 41 of later, krijg je een foutmelding. Andersom werkt het net zo min.
Elke repository die je toevoegt, is een partij die je vertrouwt. Een repository kan pakketten leveren die andere pakketten overschrijven. Voeg je een repository toe voor één pakket, dan kan diezelfde repository bij een latere update ineens andere software vervangen. DNF waarschuwt je niet standaard.
De `priority`-instelling in een `.repo`-bestand bepaalt welke repository voorgaat. Zonder die instelling kiest DNF op basis van versienummer, wat kan betekenen dat een pakket uit een minder betrouwbare bron een pakket uit de officiële repositories vervangt.
De prijs van gemak
DNF lost afhankelijkheden automatisch op. Dat is precies wat je wil, tot het misgaat.Als twee repositories hetzelfde pakket aanbieden in verschillende versies, kiest DNF de hoogste. Soms is dat wat je wil. Soms breekt het een pakket dat afhankelijk is van een specifieke versie. DNF meldt dat niet altijd even duidelijk. Je krijgt een dependency conflict en moet zelf uitzoeken welke repository de schuldige is.
```bash sudo dnf repoquery --whatprovides nginx ```
Dat vertelt je welke repositories een pakket leveren. Handig als je wil weten waar iets vandaan komt voordat je het installeert.
Er is ook de kwestie van de metadata. DNF haalt bij elke operatie de metadata van alle ingeschakelde repositories op. Op een systeem met tien repositories en een trage verbinding kost dat tijd. Je kunt dat versnellen met `--refresh` weglaten als je zeker weet dat de metadata recent is, maar dat is een afweging tussen snelheid en actualiteit.
DNF5, en waarom je er vroeg of laat mee te maken krijgt
De overstap naar DNF5 is geen cosmetische wijziging. De code is opnieuw geschreven, de prestaties zijn beter, en op termijn volgen RHEL en de afgeleide distributies. Voor nu draait RHEL 9 nog op de oude DNF. RHEL 10 zal DNF5 meenemen, en daarmee ook Rocky Linux 10 en AlmaLinux 10.Wat dat voor jou betekent: als je scripts schrijft die vandaag werken op Rocky 9, test ze voordat je naar versie 10 gaat. De commando's voor dagelijks gebruik zijn gelijk. De configuratie-opties en de plugin-interface niet.
Voor wie nu een nieuwe server opzet, is de keuze beperkt. Je neemt wat je distributie meelevert. Wil je DNF5 op een systeem dat het niet standaard heeft, dan moet je het zelf bouwen of een distributie kiezen die het al gebruikt.
Waar het op neerkomt
DNF is geen tool die je kiest. Het is de tool die je krijgt op de distributie die je koos. De vraag is of je distributie je bevalt, niet of DNF je bevalt.Wil je stabiliteit voor jaren, dan is RHEL 9 met de oude DNF een prima keuze. Wil je de nieuwste versie en de bijbehorende prestaties, dan is Fedora 41 of later met DNF5 wat je zoekt. Wil je iets ertussenin, dan zijn Rocky en AlmaLinux de voor de hand liggende opties, met de kanttekening dat ze de RHEL-cyclus volgen en dus later overstappen dan Fedora.
Wat je ook kiest, de commando's die je dagelijks typt zijn hetzelfde. De leercurve is klein. De verrassingen zitten in de details: welke repository wat levert, welke plugin nog werkt, en of je documentatie de juiste versie aanhaalt.
Dat laatste is misschien wel het belangrijkste. Een handleiding die `yum` zegt op een systeem met DNF werkt meestal nog, want yum is op de meeste systemen een symlink. Een handleiding die `--add-repo` zegt op Fedora 41 werkt niet. Het verschil tussen die twee is niet de tool. Het is de versie.