Nylig Fedora-utviklere gjorde kjent sine intensjoner om å migrere distribusjonen til den nye pakkebehandleren kalt "Micronf" i stedet fra pakkelederen "DNF" som brukes i dag.
Det første steget på veien til migrasjon vil være en stor oppdatering av Microdnf, planlagt for Fedora 38, som vil komme nær DNF i funksjonalitet og til og med overgå den på noen områder.
Det er nevnt at intensjonene å gjennomføre denne migreringen skyldes nøkkelforskjellen mellom Microdnf og DNF er bruken av C i stedet for Python for utvikling, som lar deg bli kvitt mange avhengigheter.
På et tidspunkt erstattet DNF Yum, som i sin helhet ble skrevet i Python, og i DNF ble ytelseskrevende funksjoner på lavt nivå skrevet om og flyttet til separate hawkey-, librepo-, libsolv- og libcomps C-biblioteker, men rammeverket og høy- nivåkomponenter forble i Python-språket.
Microdnf ble opprinnelig utviklet som en forenklet versjon av DNF for bruk i Docker-containere som ikke krever at Python ble installert. Nå planlegger Fedora-utviklerne å bringe Microdnf til nivået av DNF-funksjonalitet og til slutt erstatte DNF fullstendig med Microdnf.
En stor oppdatering til Microdnf er det første trinnet i utviklingen av pakkehåndtering i Fedora. Den nye microdnf har ambisjonen om å tilby alle kjernefunksjonene til DNF uten å miste sitt minimale fotavtrykk.
Microdnf er basert på libdnf5-biblioteket, utviklet som en del av DNF 5-prosjektet. DNF 5 tar sikte på å forene eksisterende lavnivåbiblioteker, omskrive de gjenværende Python-pakkehåndteringsoperasjonene i C++, og flytte kjernefunksjonalitet til et eget bibliotek med opprettelse av en binding rundt dette biblioteket for å bevare Python API.
MICRODNF forbedrer brukeropplevelsen betydelig og vil gi alle de viktige funksjonene til DNF i fremtiden. Det vil også opprettholde alle fordelene til den originale MICRODNF, for eksempel minimumsstørrelsen som kreves for containere.
Den nye versjonen av Microdnf vil også bruke bakgrunnsprosessen DNF Daemon, erstatter PackageKit-funksjonaliteten og gir et grensesnitt for å administrere pakker og oppdateringer i grafiske miljøer. I motsetning til PackageKit, vil DNF Daemon kun støtte RPM-formatet.
Microdnf, libdnf5 og DNF Daemon skal etter planen sendes sammen med det tradisjonelle DNF-verktøysettet i den første fasen av implementeringen. Når prosjektet er fullført, vil den nye pakken erstatte pakker som dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora og python3-dnfdaemon.
Av områder hvor Microdnf er DNF overlegen, skiller det seg ut: en mer visuell indikasjon på fremdriften av operasjoner; forbedret transaksjonstabellimplementering; muligheten til å vise informasjon i rapporter om fullførte transaksjoner som er utstedt av pakkede scriptlets (scriptlets); støtte for bruk av lokale RPM-pakker for transaksjoner; mer avansert inndatafullføringssystem for bash; støtte for å kjøre builddep-kommandoen uten å installere Python på systemet.
Blant ulempene endre distroens pakkebehandling til Microdnf er endringen i strukturen til de interne databasene og behandlingen av den separate databasen fra DNF, som ikke vil tillate deg å se transaksjoner med pakker laget i DNF i Microdnf og omvendt.
Pakker som tidligere er installert med DNF vil bli behandlet som "bruker installert fra dnf-historikk" etter migrering til Microdnf, og avinstallering av en pakke installert av en annen pakkebehandling vil ikke fjerne ubrukte avhengigheter knyttet til den. Microdnf planlegger heller ikke å opprettholde 100 % DNF-støtte på kommandonivå og kommandolinjealternativer.
Det bemerkes at den nye versjonen av Microdnf vil støtte alle hovedfunksjonene til DNF, men samtidig beholde høy ytelse og kompakthet.
Til slutt, hvis du er interessert i å kunne vite mer om det, kan du konsultere detaljene i følgende lenke.
Jeg er ny på programmering, og entusiastisk for Linux. Jeg har aldri brukt Fedora fordi jeg alltid har et problem med installasjonen og ender opp med Debian (og derivater) eller OpenSUSE. Men jeg tror jeg forstår viktigheten i Linux-verdenen, og hvor relevant det som skjer i Fedora.
Min tvil kommer fra ideen om å erstatte Python med C/C++, hvorfor implementere med et lavnivåspråk som har blitt sterkt kritisert for sine varianter og sin dårlig definerte standard? Jeg forstår litt endringen fra et tolket språk til et kompilert, men jeg forstår ikke hoppet til et språk som jeg har sett at det søkes brukt mindre for på enkelte områder. Ville det ikke vært bedre å ha brukt Rust eller C#?
Jeg kritiserer ikke beslutningene til folket i Fedora, men søker å forstå hvordan programmeringsverdenen utvikler seg. Jeg lærer Python og JS på nettet, og tenkte jeg skulle hoppe tilbake til C/C++ for det grunnleggende, så dette notatet virker som det kan hjelpe meg med fokus.
Tusen takk! Og utmerket arbeid som alltid til folket i <•DesdeLinux