For nylig Fedora-udviklere tilkendegav deres intentioner om at migrere distributionen til den nye pakkehåndtering kaldet "Microdnf" i stedet for fra pakkeadministratoren "DNF" der bruges i øjeblikket.
Det første skridt på vejen til migrering vil være en større opdatering af Microdnf, planlagt til Fedora 38, som i funktionalitet vil komme tæt på DNF og endda overgå den på nogle områder.
Det nævnes det intentionerne at gennemføre denne migration skyldes den vigtigste forskel mellem Microdnf og DNF er brugen af C i stedet for Python til udvikling, som giver dig mulighed for at slippe af med en masse afhængigheder.
På et tidspunkt erstattede DNF Yum, som udelukkende var skrevet i Python, og i DNF blev præstationskrævende lavniveaufunktioner omskrevet og flyttet til separate hawkey-, librepo-, libsolv- og libcomps C-biblioteker, men rammen og høj- niveaukomponenter forblev i Python-sproget.
Microdnf blev oprindeligt udviklet som en forenklet version af DNF til brug i Docker-containere, der ikke krævede, at Python skulle installeres. Nu planlægger Fedora-udviklerne at bringe Microdnf til niveauet for DNF-funktionalitet og til sidst fuldstændigt erstatte DNF med Microdnf.
En større opdatering til Microdnf er det første skridt i udviklingen af pakkehåndtering i Fedora. Den nye microdnf har ambitionen om at levere alle kernefunktionerne i DNF uden at miste sit minimale fodaftryk.
Microdnf er baseret på libdnf5 bibliotek, udviklet som en del af DNF 5-projektet. DNF 5 har til formål at forene eksisterende biblioteker på lavt niveau, omskrive de resterende Python-pakkehåndteringsoperationer i C++ og flytte kernefunktionalitet til et separat bibliotek med oprettelse af en binding omkring dette bibliotek for at bevare Python API.
MICRODNF forbedrer brugeroplevelsen markant og vil levere alle de vigtige funktioner i DNF i fremtiden. Det vil også bevare alle fordelene ved den originale MICRODNF, såsom den mindste størrelse, der kræves for beholdere.
Den nye version af Microdnf vil også bruge baggrundsprocessen DNF Daemon, erstatter PackageKit-funktionaliteten og giver en grænseflade til håndtering af pakker og opdateringer i grafiske miljøer. I modsætning til PackageKit understøtter DNF Daemon kun RPM-formatet.
Microdnf, libdnf5 og DNF Daemon er planlagt til at sendes sammen med det traditionelle DNF-værktøjssæt i den første fase af implementeringen. Når projektet er færdigt, vil den nye pakke erstatte pakker som dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora og python3-dnfdaemon.
Af områder, hvor Microdnf er DNF overlegen, skiller den sig ud: en mere visuel indikation af forløbet af operationer; forbedret implementering af transaktionstabel; evnen til at vise information i rapporter om gennemførte transaktioner, der er udstedt af pakkede scriptlets (scriptlets); understøttelse af brug af lokale RPM-pakker til transaktioner; mere avanceret input-afslutningssystem til bash; understøttelse af at køre builddep-kommandoen uden at installere Python på systemet.
Blandt ulemperne ændre distroens pakkehåndtering til Microdnf er ændringen i strukturen af de interne databaser og behandlingen af den separate database fra DNF, som ikke vil tillade dig at se transaktioner med pakker lavet i DNF i Microdnf og omvendt.
Pakker, der tidligere er installeret med DNF, vil blive behandlet som "bruger installeret fra dnf-historik" efter migrering til Microdnf, og afinstallation af en pakke installeret af en anden pakkeadministrator vil ikke fjerne ubrugte afhængigheder forbundet med den. Microdnf planlægger heller ikke at opretholde 100 % DNF-understøttelse på kommandoniveau og kommandolinjeindstillinger.
Det bemærkes, at den nye version af Microdnf vil understøtte alle hovedfunktionerne i DNF, men samtidig bevare høj ydeevne og kompakthed.
Endelig, hvis du er interesseret i at kunne vide mere om det, kan du konsultere detaljerne i følgende link.
Jeg er ny til programmering og entusiastisk over Linux. Jeg har aldrig brugt Fedora, fordi jeg altid har et problem med installationen og ender med Debian (og derivater) eller OpenSUSE. Men jeg tror, jeg forstår vigtigheden i Linux-verdenen, og hvor relevant, hvad der sker i Fedora.
Min tvivl kommer fra ideen om at erstatte Python med C/C++, hvorfor implementere med et sprog på lavt niveau, der er blevet stærkt kritiseret for dets varianter og dets dårligt definerede standard? Jeg forstår lidt ændringen fra et fortolket sprog til et kompileret sprog, men jeg forstår ikke springet til et sprog, som jeg har set, at det søges brugt mindre til på nogle områder. Ville det ikke være bedre at have brugt Rust eller C#?
Jeg kritiserer ikke Fedoras folks beslutninger, men søger at forstå, hvordan programmeringsverdenen udvikler sig. Jeg er ved at lære Python og JS på nettet, og tænkte, at jeg ville springe tilbage til C/C++ for det grundlæggende, så denne note ser ud til, at den kan hjælpe mig med fokus.
Muchas gracias! Y excelente trabajo como siempre a la gente de <•DesdeLinux