In Fedora 39 zijn ze van plan te migreren naar DNF5, afgezien van de Python-componenten

Fedora 39 met de nieuwe DNF5-verpakkingstool

DNF5 moet de gebruikerservaring verbeteren en betere prestaties leveren

Ben Cotton, Fedora-programmamanager bij Red Hat, aangekondigd onlangs op de mailinglijsten, je intentie om Fedora te migreren naar pakketbeheerder DNF5 standaard.

Er wordt vermeld dat de geplande wijziging zal van kracht zijn vanaf de release van Fedora 39, De wijziging is bedoeld om de dnf-, libdnf- en dnf-cutomatic-pakketten te vervangen door de DNF5-toolkit en de nieuwe libdnf5-bibliotheek.

Wat betreft de verandering, is het vermeldenswaard dat: op het moment dat DNF Yum . verving, die volledig in Python is geschreven.

Voor degenen die niet op de hoogte zijn van DNF, Ze zouden moeten weten dat dit is een softwarepakketbeheerder die pakketten installeert, bijwerkt en verwijdert in Fedora en de opvolger is van YUM (Yellow-Dog Updater Modified). DNF vergemakkelijkt pakketonderhoud door automatisch afhankelijkheden te controleren en de acties te bepalen die nodig zijn om pakketten te installeren. Deze methode elimineert de noodzaak om het pakket en zijn afhankelijkheden handmatig te installeren of bij te werken met behulp van het rpm-commando. DNF is nu de standaard softwarepakketbeheertool in Fedora.

In DNF werden prestatie-eisende low-level functies herschreven en verplaatst naar afzonderlijke C-bibliotheken hawkey, librepo, libsolv en libcomps, maar het raamwerk en de componenten op hoog niveau bleven in Python.

DNF5 zorgt voor een aanzienlijke verbetering van de gebruikerservaring en prestaties. De vervanging is de tweede stap in het updaten van de Fedora software management stack. Zonder de wijziging zullen er meerdere softwarebeheertools (DNF5, oude Microdnf, PackageKit en DNF) zijn op basis van verschillende bibliotheken (libdnf, libdnf5), die ander gedrag bieden en geen geschiedenis delen. We kunnen ook verwachten dat DNF slechts beperkte upstream-ondersteuning heeft.

El proyecto DNF5 heeft tot doel bestaande bibliotheken op laag niveau te verenigen, herschrijven in C++ pakketbeheercomponenten die in Python blijven en kernfunctionaliteit verplaatsen naar een afzonderlijke libdnf5-bibliotheek door een koppeling rond deze bibliotheek te maken om de Python-API te behouden.

DNF5 is nog in ontwikkeling en sommige functies of opties zijn nog niet beschikbaar. We moeten de implementatie van Modularity, de opslag van interne gegevens met betrekking tot systeemgeschiedenis en -status, en ook de documentatie en man-pagina's nog afronden. DNF5 kan worden getest vanuit de repository met nachtelijke upstream-builds: d` zou niet door de gebruiker kunnen worden geschreven en het formaat is niet voldoende (informatie over geïnstalleerde pakketten met geïnstalleerde profielen ontbreekt)

Het gebruik van C++ in plaats van Python zal veel afhankelijkheden verwijderen, de grootte verkleinen van de toolset en de prestaties te verbeteren. Hogere prestaties worden niet alleen bereikt door compilatie naar machinecode te gebruiken, maar ook door verbeterde implementatie van transactietabellen, optimalisatie van het laden vanuit repositories en databaseherstructurering (afzonderlijke databases met systeemstatus en bewerkingsgeschiedenis).

DNF5 heeft zich losgekoppeld van PackageKit ten gunste van een nieuw achtergrondproces DNF-daemon die de functionaliteit van PackageKit vervangt en een interface biedt voor het beheren van pakketten en updates in grafische omgevingen.

ook herwerken Het zal het mogelijk maken om enkele verbeteringen in de bruikbaarheid van de pakketbeheerder door te voeren. Zo heeft de nieuwe DNF een meer visuele indicatie van de voortgang van operaties; ondersteuning toegevoegd voor het gebruik van lokale RPM-pakketten voor transacties; de mogelijkheid toegevoegd om in rapporten over voltooide transacties informatie weer te geven die is uitgegeven door verpakte scriptlets (scriptlets); stelde een meer geavanceerd invoeraanvullingssysteem voor bash voor.

Dat is het vermelden waard het voorstel is nog niet beoordeeld door FESCo (Fedora Engineering Steering Committee), die verantwoordelijk is voor het technische deel van de ontwikkeling van de Fedora-distributie.

Eindelijk Als u er meer over wilt weten, u kunt de details in het volgende link.


Laat je reactie achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *

*

*

  1. Verantwoordelijk voor de gegevens: AB Internet Networks 2008 SL
  2. Doel van de gegevens: Controle SPAM, commentaarbeheer.
  3. Legitimatie: uw toestemming
  4. Mededeling van de gegevens: De gegevens worden niet aan derden meegedeeld, behalve op grond van wettelijke verplichting.
  5. Gegevensopslag: database gehost door Occentus Networks (EU)
  6. Rechten: u kunt uw gegevens op elk moment beperken, herstellen en verwijderen.