Onlangs de Fedora-ontwikkelaars kondigden hun intenties aan om te migreren de distributie naar de nieuwe pakketbeheerder genoemd «Microdnf» in plaats daarvan van de pakketbeheerder "DNF" dat momenteel wordt gebruikt.
De eerste stap op weg naar migratie is een grote upgrade naar Microdnf, gepland voor Fedora 38, die qua functionaliteit DNF benadert en op sommige gebieden zelfs overtreft.
Er wordt gezegd dat de bedoelingen om genoemde migratie uit te voeren is te wijten aan het belangrijkste verschil tussen Microdnf en DNF is het gebruik van C in plaats van Python voor ontwikkeling, die stelt u in staat om van een groot aantal afhankelijkheden af te komen.
Op een gegeven moment verving DNF Yum, dat volledig in Python was geschreven, en in DNF werden prestatie-eisende low-level functies herschreven en verplaatst naar afzonderlijke hawkey-, librepo-, libsolv- en libcomps C-bibliotheken, maar het framework en het hoge niveau componenten bleven in de Python-taal.
Microdnf is oorspronkelijk ontwikkeld als een vereenvoudigde versie van DNF voor gebruik in Docker-containers waarvoor geen installatie van Python nodig was. Nu zijn de Fedora-ontwikkelaars van plan om Microdnf naar het DNF-functionaliteitsniveau te brengen en uiteindelijk DNF volledig te vervangen door Microdnf.
Een grote update van Microdnf is de eerste stap in de evolutie van pakketbeheer in Fedora. De nieuwe microdnf heeft de ambitie om alle hoofdfuncties van DNF te bieden zonder zijn minimale voetafdruk te verliezen.
Microdnf is gebaseerd op de libdnf5-bibliotheek, ontwikkeld als onderdeel van het project DNF 5. DNF 5 heeft tot doel bestaande bibliotheken op laag niveau te verenigen, de resterende pakketbeheerbewerkingen in Python in C++ te herschrijven en de kernfunctionaliteit naar een afzonderlijke bibliotheek te verplaatsen door een binding rond deze bibliotheek te creëren om de Python-API.
MICRODNF verbetert de gebruikerservaring aanzienlijk en zal in de toekomst alle belangrijke functies van DNF bieden. Het behoudt ook alle voordelen van de originele MICRODNF, zoals de minimumafmetingen die vereist zijn voor de containers.
De nieuwe versie van Microdnf zal ook het DNF Daemon-achtergrondproces gebruiken, vervangt de PackageKit-functionaliteit en biedt een interface voor het beheer van pakketten en updates in grafische omgevingen. In tegenstelling tot PackageKit ondersteunt DNF Daemon alleen het RPM-formaat.
Microdnf, libdnf5 en DNF Daemon zullen naar verwachting samen met de traditionele DNF-toolkit worden geleverd in de eerste implementatiefase. Zodra het project is voltooid, vervangt het nieuwe pakket pakketten zoals dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora en python3-dnfdaemon.
Van de gebieden waar Microdnf superieur is aan DNF, vallen op: een meer visuele indicatie van de voortgang van operaties; verbeterde implementatie van transactietabellen; de mogelijkheid om informatie weer te geven in rapporten over voltooide transacties die worden uitgegeven door verpakte scripts (scriptlets); ondersteuning voor het gebruik van lokale RPM-pakketten voor transacties; meer geavanceerd systeem voor het voltooien van invoer voor bash; ondersteuning voor het uitvoeren van de opdracht builddep zonder Python op het systeem te installeren.
Onder de nadelen om de pakketbeheerder van de distributie te wijzigen in Microdnf is de verandering in de structuur van de interne databases en aparte databaseverwerking van DNF, waardoor u geen transacties kunt zien met pakketten die in DNF zijn gemaakt in Microdnf en vice versa.
Pakketten die eerder met DNF zijn geïnstalleerd, worden behandeld als "geïnstalleerd door dnf-geschiedenisgebruiker" na migratie naar Microdnf, en het verwijderen van een pakket dat door een andere pakketbeheerder is geïnstalleerd, verwijdert geen ongebruikte afhankelijkheden die eraan zijn gekoppeld. Ook is Microdnf niet van plan om 100% DNF-compatibiliteit te behouden op het niveau van opdrachten en opdrachtregelopties.
Opgemerkt wordt dat de nieuwe versie van Microdnf alle hoofdfuncties van DNF zal ondersteunen, maar tegelijkertijd hoge prestaties en compactheid zal behouden.
Ten slotte, als u geïnteresseerd bent om er meer over te weten, kunt u raadplegen de details in de volgende link.
Ik ben nieuw in programmeren en een Linux-enthousiasteling. Ik heb Fedora nog nooit gebruikt omdat ik altijd een installatieprobleem heb en uiteindelijk op Debian (en afgeleiden) of OpenSUSE terechtkom. Maar ik denk dat ik het belang in de Linux-wereld begrijp, en hoe relevant wat er in Fedora gebeurt.
Mijn twijfel komt voort uit het idee om Python te vervangen door C / C ++, waarom implementeren met een taal op laag niveau die sterk is bekritiseerd vanwege zijn varianten en zijn slecht gedefinieerde standaard? Ik begrijp het overschakelen van een geïnterpreteerde taal naar een gecompileerde taal enigszins, maar ik begrijp de sprong naar een taal niet waarvan ik heb gezien dat mensen op sommige gebieden minder proberen te gebruiken. Was het niet beter geweest om Rust of C# te gebruiken?
Ik bekritiseer de beslissingen van de Fedora-mensen niet, maar probeer te begrijpen hoe de programmeerwereld vordert. Ik ben Python en JS aan het leren op het web, en ik dacht dat ik later in C/C++ zou springen voor de basis, dus deze opmerking lijkt me dat het me zou kunnen helpen met de aanpak.
Ontzettend bedankt! En zoals altijd uitstekend werk voor de mensen van <•DesdeLinux