DNF 5 in Development

-
Red Hat Pushing DNF 5 Into Development For Improving The Package Manager
The Yum successor DNF on Fedora and Red Hat Linux distributions (among other select RPM distributions) is soon embarking on its fifth major iteration.
Red Hat developers are starting work on DNF 5 as the next major version of this RPM package management solution. DNF 5 is being developed now in order to allow for API/ABI breakage, particularly with moving away from PackageKit and in its place developing a new DBus service to provide an interface to GUI-based package management applications.
-
Announcing start of DNF 5 development
Hello everyone, I'm pleased to announce start of DNF 5 development. We are planning to deliver a module stream or a COPR repo during Fedora 33 development for early adopters and tool developers and we're hoping in getting a stable version into Fedora 34. More details follow. We've managed to drop a lot of redundant code across the whole DNF stack in the past years, but we have reached a point when it's nearly impossible to consolidate the code any further without breaking the API/ABI. Especially with PackageKit being dead[1], we can't move with the old "libhif" API in libdnf, because making any bigger changes to PackageKit is clearly out of scope. [1] https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-... That's why we decided to start working on a new version of the DNF stack: DNF 5. And this is the plan: Priorities ---------- 1. Consistency, documentation and user experience is the top priority. 2. Compatibility on the command line level. 3. Compatibility on the API level. Maintenance ----------- The existing DNF 4 stack stays in the current Fedoras and Red Hat Enterprise Linux 8. We'll keep maintaining it in dnf-4-master branches on GitHub. PackageKit and rpm-ostree will stay on libdnf from the DNF 4 stack. The existing Python API in DNF ------------------------------ The Python API in DNF stays. We'll do our best to keep it working. If there is an incompatible change, we'll communicate and document it properly. The new API in libdnf --------------------- All business logic will move from DNF (Python) to libdnf (C++). This is the only way to ensure that package managers work identically across the whole distribution. We'll start with C++ API and auto-generated Python bindings via SWIG. We'll focus on the Python bindings which are required by DNF and we will do our best to provide bindings for Go, Perl5 and Ruby as well. C API will be created later when the C++ API is stable. At that moment rpm-ostree will be ported to the new C API. hawkey ------ Hawkey Python API is going away and will be replaced with libdnf Python API. DNF --- DNF stays as the primary command-line package manager. The overall functionality remains. We don't anticipate any negative impact of the API rewrite on the end-users. We have built an extensive test suite (over 1400 scenarios) that will help us to ensure that. The argument parser and outputs may slightly change in some cases to provide a more consistent user-experience. All such cases will be properly documented. microdnf -------- Microdnf is becoming important because it's part of many containers due to its small footprint. We're getting feedback that users would appreciate something closer to DNF. We'll focus on implementing a subset of DNF's functionality and improving the user experience. 100% feature parity with DNF is currently out of scope. DBus service ------------ DNF team has decided to create a new DBus service replacing PackageKit to provide an interface to GUI applications. It's probably going to take a while because we're planning to start from scratch. Roadmap (tentative) ------------------- * Mar 2020 - making the bigger API changes, upstream code barely compiles * May 2020 - COPR repo with first development snapshots * Jun 2020 - F33 module available for early adopters and tool developers * Oct 2020 - DNF 5 landing in F34 Rawhide * Feb 2021 - DNF 5 replacing DNF 4 in stable Fedora
-

- Login or register to post comments
Printer-friendly version- 2713 reads
PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
digiKam 7.7.0 is released
After three months of active maintenance and another bug triage, the digiKam team is proud to present version 7.7.0 of its open source digital photo manager. See below the list of most important features coming with this release.
|
Dilution and Misuse of the "Linux" Brand
|
Samsung, Red Hat to Work on Linux Drivers for Future Tech
The metaverse is expected to uproot system design as we know it, and Samsung is one of many hardware vendors re-imagining data center infrastructure in preparation for a parallel 3D world.
Samsung is working on new memory technologies that provide faster bandwidth inside hardware for data to travel between CPUs, storage and other computing resources. The company also announced it was partnering with Red Hat to ensure these technologies have Linux compatibility.
|
today's howtos
|








.svg_.png)
Content (where original) is available under CC-BY-SA, copyrighted by original author/s.

Recent comments
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago