În Fedora ei plănuiesc să înlocuiască DNF cu Microdnf

Recent, Dezvoltatorii Fedora și-au făcut cunoscute intențiile de a migra distribuția către noul manager de pachete numit „Microdnf” în schimb de la managerul de pachete „DNF” care este utilizat în prezent.

Primul pas pe drumul către migrație va fi o actualizare majoră a Microdnf, planificat pentru Fedora 38, care se va apropia ca funcționalitate de DNF și chiar o va depăși în unele zone.

Se menționează că intentiile a efectua această migrare se datorează diferența cheie dintre Microdnf și DNF este utilizarea lui C în loc de Python pentru dezvoltare, care vă permite să scăpați de o mulțime de dependențe.

La un moment dat, DNF l-a înlocuit pe Yum, care a fost scris în întregime în Python, iar în DNF, funcțiile de nivel scăzut care necesită performanță au fost rescrise și mutate în bibliotecile C separate hawkey, librepo, libsolv și libcomps, dar cadrul și componentele de nivel au rămas în limbajul Python.

Microdnf a fost dezvoltat inițial ca o versiune simplificată a DNF pentru utilizare în containerele Docker care nu necesitau instalarea Python. Acum, dezvoltatorii Fedora plănuiesc să aducă Microdnf la nivelul de funcționalitate DNF și în cele din urmă să înlocuiască complet DNF cu Microdnf.

O actualizare majoră a Microdnf este primul pas în evoluția managementului pachetelor în Fedora. Noul microdnf are ambiția de a oferi toate caracteristicile de bază ale DNF fără a-și pierde amprenta minimă.

Microdnf se bazează pe biblioteca libdnf5, dezvoltat ca parte a proiectului DNF 5. DNF 5 își propune să unifice bibliotecile de nivel scăzut existente, să rescrie operațiunile rămase de gestionare a pachetelor Python în C++ și să mute funcționalitatea de bază într-o bibliotecă separată cu crearea unei legături în jurul acestei biblioteci pentru a păstra API-ul Python.

MICRODNF îmbunătățește semnificativ experiența utilizatorului și va oferi toate caracteristicile importante ale DNF în viitor. De asemenea, va menține toate avantajele MICRODNF original, cum ar fi dimensiunea minimă necesară pentru containere.

Noua versiune de Microdnf va folosi, de asemenea, procesul de fundal DNF Daemon, înlocuind funcționalitatea PackageKit și oferind o interfață pentru gestionarea pachetelor și actualizărilor în medii grafice. Spre deosebire de PackageKit, Daemonul DNF va accepta doar formatul RPM.

Microdnf, libdnf5 și DNF Daemon sunt programate să fie livrate împreună cu setul de instrumente DNF tradițional în prima fază de implementare. Odată ce proiectul este finalizat, noul pachet va înlocui pachete precum dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora și python3-dnfdaemon.

Dintre zonele in care Microdnf este superior DNF, iese in evidenta: o indicație mai vizuală a progresului operațiunilor; implementare îmbunătățită a tabelului de tranzacții; capacitatea de a afișa informații în rapoarte despre tranzacțiile finalizate care sunt emise de scriptlet-uri (scriptlet-uri) ambalate; suport pentru utilizarea pachetelor RPM locale pentru tranzacții; sistem mai avansat de completare a intrărilor pentru bash; suport pentru rularea comenzii builddep fără a instala Python pe sistem.

Printre dezavantaje schimbarea managerului de pachete al distribuției în Microdnf este modificarea structurii bazelor de date interne si prelucrarea bazei de date separate de la DNF, care nu va permite sa vedeti tranzactii cu pachete realizate in DNF in Microdnf si invers.

Pachetele instalate anterior cu DNF vor fi tratate ca „utilizator instalat din istoricul dnf” după migrarea la Microdnf, iar dezinstalarea unui pachet instalat de un alt manager de pachete nu va elimina dependențele neutilizate asociate cu acesta. De asemenea, Microdnf nu intenționează să mențină suport 100% DNF la nivel de comandă și opțiunile liniei de comandă.

Se observă că noua versiune a Microdnf va susține toate caracteristicile principale ale DNF, dar va păstra în același timp performanța și compactitatea ridicate.

În cele din urmă, dacă sunteți interesat să puteți afla mai multe despre aceasta, puteți consulta detaliile din următorul link.


Lasă comentariul tău

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *

*

*

  1. Responsabil pentru date: Miguel Ángel Gatón
  2. Scopul datelor: Control SPAM, gestionarea comentariilor.
  3. Legitimare: consimțământul dvs.
  4. Comunicarea datelor: datele nu vor fi comunicate terților decât prin obligație legală.
  5. Stocarea datelor: bază de date găzduită de Occentus Networks (UE)
  6. Drepturi: în orice moment vă puteți limita, recupera și șterge informațiile.

  1.   khort el a spus

    Sunt nou în programare și sunt entuziasmat de Linux. Nu am folosit niciodată Fedora pentru că mereu am o problemă cu instalarea și ajung la Debian (și derivate) sau OpenSUSE. Dar cred că înțeleg importanța în lumea Linux și cât de relevant se întâmplă în Fedora.
    Îndoiala mea vine de la ideea de a înlocui Python cu C/C++, de ce să implementez cu un limbaj de nivel scăzut care a fost foarte criticat pentru variantele sale și standardul său prost definit? Înțeleg puțin trecerea de la un limbaj interpretat la unul compilat, dar nu înțeleg saltul la un limbaj pentru care am văzut că se caută folosirea mai puțin în unele domenii. Nu ar fi mai bine să fi folosit Rust sau C#?
    Nu critic deciziile oamenilor din Fedora, ci caut să înțeleg cum avansează lumea programării. Învăț Python și JS pe web și m-am gândit că voi reveni la C/C++ pentru elementele de bază, așa că această notă pare că m-ar putea ajuta să mă concentrez.

    Mulțumesc foarte mult! Și munca excelentă ca întotdeauna pentru oamenii din <•DesdeLinux