dnf: Pakketbeheer

DNF staat op je systeem zodra je Fedora 22 of later installeert, of RHEL 8 en nieuwer. Je typt `dnf install` en het werkt. Wat er onder die motorkap zit te draaien, en waarom dat je zou moeten interesseren, is een ander verhaal.

Want je hebt een keuze te maken. Niet of je DNF gebruikt — dat doe je al, of je krijgt het opgedrongen door je distributie. De keuze is welke RPM-distributie je kiest, en hoeveel je bereid bent te betalen voor zekerheid die je zelf niet hoeft te onderhouden.

DNF is de opvolger van YUM. Die naam, Dandified YUM, verraadt precies wat het is: hetzelfde idee, opnieuw gebouwd. Waar YUM jarenlang de standaard was in Red Hat-gebaseerde systemen, nam DNF het over omdat YUM vastliep op prestatie en afhankelijkheidsresolutie. Als je ooit hebt gewacht tot YUM klaar was met nadenken over een dependency tree, weet je waarom iemand daar iets aan wilde doen.

Fedora 18, 2013, was de eerste verschijning. Niet als standaard, alleen als beschikbaar. Je moest het zelf installeren of expliciet aanroepen. Pas in Fedora 22, 2015, werd `dnf` de pakketbeheerder die automatisch draait bij `dnf install`, `dnf update` en `dnf remove`. Vanaf dat moment was de rolverdeling duidelijk.

RHEL 8 volgde in 2019. Dat is de versie die de meeste enterprise-omgevingen nu draaien, of een kloon daarvan. Red Hat heeft DNF niet zelf bedacht om Fedora te pleasen — het is dezelfde code die eerst in Fedora werd uitgeprobeerd en daarna in productieomgevingen belandde. Dat is het hele punt van Fedora als proefplatform.

Wat je daarvoor terugkrijgt, zit in `libdnf`. Dat is de bibliotheek onder de motorkap, en die is in de loop der jaren twee keer van taal veranderd. In 2016 begon een gedeeltelijke port van Python naar C, om de prestaties op te krikken en de afhankelijkheid van de Python-interpreter te verminderen. In 2018 ging `libdnf` van C naar C++. Objectgeoriënteerd programmeren, makkelijker te onderhouden codebase. Voor jou als gebruiker verandert er niets aan de commando's — de interface bleef in grote lijnen compatibel met YUM. Voor de mensen die het onderhouden scheelt het een hoop.

Een van de dingen die DNF echt bruikbaar maakt in de praktijk is `dnf history`. Je krijgt een overzicht van elke pakkettransactie die op het systeem is uitgevoerd. Datum, tijd, aantal pakketten, of het gelukt is of afgebroken, of de RPM-database is gewijzigd.

`dnf history list` geeft je de samenvatting. `dnf history info [nummer]` geeft je de details: welke pakketten geïnstalleerd, bijgewerkt of verwijderd zijn. Als een update iets heeft gesloopt, kun je terug. Dat is geen luxe. Dat is het verschil tussen een systeem dat je kunt herstellen en een systeem dat je opnieuw moet opbouwen.

Nu de distributies. Je kunt Fedora draaien. Dan krijg je de nieuwste DNF, de nieuwste alles, en een release-cyclus van ongeveer een half jaar. Je bent het proefkonijn. Soms is dat leuk, soms niet.

Of je kiest RHEL. Dat kost geld, tenzij je de gratis developer-subscription gebruikt, en die heeft grenzen aan het aantal systemen. Wat je terugkrijgt is stabiliteit, een ondersteuningstermijn van tien jaar per major versie, en een leverancier die je kunt bellen als het misgaat. Voor sommige organisaties is dat de rekening waard. Voor andere niet.

Dan zijn er de klonen. Rocky Linux en AlmaLinux. Beide ontstaan nadat CentOS in 2020 veranderde van een stabiele RHEL-kloon in een rolling release die voorliep op RHEL. Dat besloot het vertrouwen van een hele groep beheerders. Rocky Linux, opgericht door Gregory Kurtzer, en AlmaLinux, ontwikkeld door CloudLinux Inc., vullen dat gat.

Beide zijn 1:1 binair compatibel met RHEL. Ze volgen dezelfde versienummering — Rocky Linux 8, AlmaLinux 9, enzovoort — en bieden dezelfde tien jaar ondersteuning per major versie. Ze gebruiken DNF als standaard pakketbeheerder en werken met de officiële RHEL-repositories. Pakketten die op RHEL werken, werken hier zonder aanpassing.

Dat is het punt: je krijgt de RHEL-ervaring zonder de RHEL-factuur. Wat je inlevert is de commerciële ondersteuning en, in sommige gevallen, certificeringen die alleen RHEL mag voeren.

AlmaLinux heeft er één die het vermelden waard is: FIPS 140-3-certificering. Voor overheden en financiële instellingen die aan strenge beveiligingsnormen moeten voldoen, is dat geen detail. Het betekent dat bepaalde cryptografische componenten op een specifieke manier geconfigureerd en gevalideerd zijn. DNF respecteert dat beleid en werkt samen met de onderliggende RPM-infrastructuur om het niet te breken.

Rocky Linux heeft die certificering in een andere vorm, en de precieze status verschuift per release. Als FIPS voor jou een harde eis is, controleer het per versie. Niet aannemen.

Dus wat kies je.

Fedora als je wilt meedoen aan de voorkant, nieuwe dingen wilt testen, en het niet erg vindt dat je systeem elke zes maanden een sprong maakt. Kost je tijd, levert je nieuwigheid.

RHEL als je een leverancier wilt die je bijstaat als het misgaat, en je de licentie kunt verantwoorden. Kost je geld, levert je rust.

Rocky of Alma als je RHEL-compatibiliteit wilt zonder de factuur, en je het niet erg vindt dat de ondersteuning van de community komt in plaats van een contract. Kost je niets, behalve de wetenschap dat je bij een echt probleem op een forum zit te wachten.

Wat je ook kiest, DNF staat eronder. Het is de laag die je nooit ziet als alles werkt, en waar je meteen naar grijpt als het niet werkt. `dnf history` is je eerste commando als iets is misgegaan. Dat is geen functie die je waardeert tot je hem nodig hebt.

En dat is misschien het eerlijkste wat je over pakketbeheer kunt zeggen: het is onzichtbaar tot het moment dat je het nodig hebt, en dan is het te laat om er nog over na te denken. Kies je distributie dus voordat er iets omvalt, niet erna.