Re: Announcing start of DNF 5 development

[Neal Gompa]

On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek
 wrote:
> 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...
> >
> > That's why we decided to start working on a new version of the DNF
> > stack: DNF 5. And this is the plan:
> > Priorities
> > Consistency, documentation and user experience is the top priority.
> > Compatibility on the command line level.
> > 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?

This would be interesting, but wouldn't that make using DNF in rescue
situations impossible?
> (And e.g. provide a single cache and privilege escalation through
> packagekit)?

We can do the single cache thing *today* for PackageKit. The APIs
exist in libdnf _now_, it's just that they're not used
PackageKit-side.
> Apart from the dbus api, do you plan to provide some graphical
> application that uses this api?

I would expect that dnfdragora will be the first consumer of this new
API, since this plan would essentially involve taking over the role of
my dnfdaemon.
> Are you going to use sd-bus for the dbus library?

I'd hope not, given that we have cross-distro usage of DNF now, and a
couple of them don't have systemd.