Dne 04. 03. 20 v 22:34 Zbigniew Jędrzejewski-Szmek napsal(a):
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!
Thanks!
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)?
No, dnf stays as it is, it's not going to switch to dbus.
Single cache is part of the plan.
Apart from the dbus api, do you plan to provide some graphical
application that uses this api?
Definitely not at this moment.
We need to build the new service and integrate it with the existing
tools first. We may create a simple command-line tool replacing pkcon,
something like microdnf over dbus.
Are you going to use sd-bus for the dbus library?
Yes, it's going to be sd-bus + sdbus-cpp:
* https://github.com/Kistler-Group/sdbus-cpp
* https://src.fedoraproject.org/rpms/sdbus-cpp
_______________________________________________
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
