Το DNF5 θα βελτιώσει την εμπειρία χρήστη και θα παρέχει καλύτερη απόδοση
Ben Cotton, Διευθυντής Προγράμματος Fedora στο RedHat, ανακοίνωσε πρόσφατα στις λίστες αλληλογραφίας, την πρόθεσή σας να μεταναστεύσετε το Fedora στον διαχειριστή πακέτων DNF5 από προεπιλογή.
Αναφέρεται ότι η προγραμματισμένη αλλαγή θα ισχύσει από την κυκλοφορία του Fedora 39, Η αλλαγή σχεδιάζει να αντικαταστήσει τα πακέτα dnf, libdnf και dnf-cutomatic με το κιτ εργαλείων DNF5 και τη νέα βιβλιοθήκη libdnf5.
Σχετικά με την αλλαγή, αξίζει να αναφέρουμε ότι τη στιγμή που το DNF αντικατέστησε το Yum, το οποίο γράφτηκε εξ ολοκλήρου σε Python.
Για όσους δεν γνωρίζουν το DNF, Θα πρέπει να το γνωρίζουν αυτό είναι διαχειριστής πακέτων λογισμικού που εγκαθιστά, ενημερώνει και καταργεί πακέτα στο Fedora και είναι ο διάδοχος του YUM (Yellow-Dog Updater Modified). DNF διευκολύνει τη συντήρηση του πακέτου ελέγχοντας αυτόματα τις εξαρτήσεις και προσδιορίζοντας τις ενέργειες που απαιτούνται για την εγκατάσταση πακέτων. Αυτή η μέθοδος εξαλείφει την ανάγκη μη αυτόματης εγκατάστασης ή ενημέρωσης του πακέτου και των εξαρτήσεων του χρησιμοποιώντας την εντολή rpm. Το DNF είναι πλέον το προεπιλεγμένο εργαλείο διαχείρισης πακέτων λογισμικού στο Fedora.
Στο DNF, συναρτήσεις χαμηλού επιπέδου που απαιτούν απόδοση ξαναγράφτηκαν και μετακινήθηκε σε ξεχωριστές βιβλιοθήκες C hawkey, librepo, libsolv και libcomps, αλλά το πλαίσιο και τα στοιχεία υψηλού επιπέδου παρέμειναν στην Python.
Το DNF5 θα προσφέρει σημαντική βελτίωση στην εμπειρία και την απόδοση του χρήστη. Η αντικατάσταση είναι το δεύτερο βήμα για την ενημέρωση της στοίβας διαχείρισης λογισμικού Fedora. Χωρίς την αλλαγή, θα υπάρχουν πολλά εργαλεία διαχείρισης λογισμικού (DNF5, παλιό Microdnf, PackageKit και DNF) βασισμένα σε διαφορετικές βιβλιοθήκες (libdnf, libdnf5), που θα παρέχουν διαφορετική συμπεριφορά και δεν θα μοιράζονται το ιστορικό. Μπορούμε επίσης να περιμένουμε ότι το DNF θα έχει περιορισμένη μόνο υποστήριξη upstream.
Το έργο Το DNF5 στοχεύει να ενοποιήσει υπάρχουσες βιβλιοθήκες χαμηλού επιπέδου, να ξαναγράψει σε C++ στοιχεία διαχείρισης πακέτων που παραμένουν στην Python και μεταφέρουν τη βασική λειτουργικότητα σε μια ξεχωριστή βιβλιοθήκη libdnf5 δημιουργώντας έναν σύνδεσμο γύρω από αυτήν τη βιβλιοθήκη για τη διατήρηση του Python API.
Το DNF5 είναι ακόμα υπό ανάπτυξη και ορισμένες από τις δυνατότητες ή τις επιλογές δεν είναι ακόμη διαθέσιμες. Πρέπει ακόμα να ολοκληρώσουμε την υλοποίηση του Modularity, την αποθήκευση εσωτερικών δεδομένων που σχετίζονται με το Ιστορικό και την Κατάσταση Συστήματος, καθώς και την τεκμηρίωση και τις σελίδες man. Το DNF5 μπορεί να ελεγχθεί από το χώρο αποθήκευσης με νυχτερινές ανανεωμένες εκδόσεις: το d` δεν έπρεπε να είναι εγγράψιμο από τον χρήστη και η μορφή του δεν είναι επαρκής (δεν υπάρχουν πληροφορίες σχετικά με τα εγκατεστημένα πακέτα με εγκατεστημένα προφίλ)
Η χρήση C++ αντί για Python θα αφαιρέσει πολλές εξαρτήσεις, θα μειώσει το μέγεθος του συνόλου εργαλείων και να βελτιώσει την απόδοση. Η υψηλότερη απόδοση επιτυγχάνεται όχι μόνο με τη χρήση μεταγλώττισης σε κώδικα μηχανής, αλλά και λόγω της βελτιωμένης υλοποίησης του πίνακα συναλλαγών, της βελτιστοποίησης της φόρτωσης από τα αποθετήρια και της αναδιάρθρωσης της βάσης δεδομένων (ξεχωριστές βάσεις δεδομένων με κατάσταση συστήματος και ιστορικό λειτουργίας).
DNF5 έχει αποσυνδεθεί από το PackageKit υπέρ του μια νέα διαδικασία φόντου DNF Daemon που αντικαθιστά τη λειτουργικότητα του PackageKit και παρέχει μια διεπαφή για τη διαχείριση πακέτων και ενημερώσεων σε γραφικά περιβάλλοντα.
ξαναδουλέψτε επίσης Θα επιτρέψει την εφαρμογή ορισμένων βελτιώσεων στη χρηστικότητα του διαχειριστή πακέτων. Για παράδειγμα, το νέο DNF έχει μια πιο οπτική ένδειξη της προόδου των λειτουργιών. προστέθηκε υποστήριξη για τη χρήση τοπικών πακέτων RPM για συναλλαγές. πρόσθεσε τη δυνατότητα εμφάνισης πληροφοριών που εκδίδονται από συσκευασμένα scriptlets (scriptlets) σε αναφορές για ολοκληρωμένες συναλλαγές. πρότεινε ένα πιο προηγμένο σύστημα ολοκλήρωσης εισόδου για το bash.
Αξίζει να το αναφέρουμε η πρόταση δεν έχει ακόμη αναθεωρηθεί από την FESCO (Fedora Engineering Steering Committee), η οποία είναι υπεύθυνη για το τεχνικό μέρος της ανάπτυξης της διανομής Fedora.
Τελικά Εάν ενδιαφέρεστε να μάθετε περισσότερα γι 'αυτό, μπορείτε να ελέγξετε τις λεπτομέρειες στο παρακάτω σύνδεσμο.