On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote: > 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-dead-long-live-well-something-else/ > > > 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. > > Hi, the roadmap is ambitious, but not impossible. Good luck! > 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 > 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. Do you plan to make normal 'dnf' calls go through the dbus api? (And e.g. provide a single cache and privilege escalation through packagekit)? Apart from the dbus api, do you plan to provide some graphical application that uses this api? Are you going to use sd-bus for the dbus library? Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
