On Thu, 2020-03-05 at 09:11 +0100, Fabio Valentini wrote: > On Thu, Mar 5, 2020, 08:56 <jkone...@redhat.com> wrote: > > On Thu, 2020-03-05 at 07:44 +0100, Fabio Valentini wrote: > > > On Thu, Mar 5, 2020, 00:55 Martin Kolman <mkol...@redhat.com> wrote: > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Neal Gompa" <ngomp...@gmail.com> > > > > > > > > > To: "Development discussions related to Fedora" > > > > > <devel@lists.fedoraproject.org> > > > > > > > > > Sent: Wednesday, March 4, 2020 11:01:43 PM > > > > > > > > > Subject: Re: Announcing start of DNF 5 development > > > > > > > > > > > > > > > > > > On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek > > > > > > > > > <zbys...@in.waw.pl> 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-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? > > > > > > > > > > > > > > > > > > This would be interesting, but wouldn't that make using DNF in rescue > > > > > > > > > situations impossible? > > > > > > > > You mean due to the regular DBus daemon & system + session bus not > > > > running > > > > > > > > in some system rescue scenarios, right ? > > > > > > > > > > > > > > > > While possibly a bit tricky I could imagine some fallback mechanism > > > > where > > > > > > > > invocation of the CLI tool starts it's own DBus session & instance of > > > > the DNF > > > > > > > > service when it detects that the regular system & session buses are not > > > > available. > > > > > > > > > > > > > > > > Anaconda does something similar when it starts in Mock during some > > > > phases of the > > > > > > > > compose process & finds no system bus is available - it starts it's own > > > > DBus daemon > > > > > > > > process and uses that. > > > > > > Wow, using dbus to communicate between CLI binary and the shared library > > > sounds like an awful idea. Why not do a > > > simple shim around the shared library instead? (And not introduce another > > > 2 moving parts into a critical system > > > component: dnf dbus service and dnf dbus client) > > > > > > Fabio > > > > Aside of others, it will help to solve a dead locks when DNF is accessing > > system resources and DB. Right now, > > Anaconda is launching DNF/YUM in a separate process because otherwise we > > will be locked by Python GIL (Global > > Interpreter Lock) on every C call in the DNF library from python. Another > > reason is to replace PackageKit by > > something which is not dead or have a possibility to replace it. > > > > Second benefit is DBus is language agnostic so you could use any > > programming language you want to use DNF. > > > > Jirka > > I think my message was a bit ambiguous. I meant to say: > > I hope you don't use the dbus daemon to communicate between /usr/bin/dnf and > /usr/lib64/libdnf.so.666, which would > only introduce 3 more moving parts. > > As for providing a dbus-based API in addition to the shared library, of > course I'm all for that, for all the reasons > you stated in your response. > > And in another message in this thread, somebody already clarified that the > dnf binary won't use libdnf over dbus, but > link to the shared library directly. So my concerns seem to be invalid. :) Sure, as long as you make sure that operations initiated over DBus do not clash with operations initiated from CLI you really don't need to have the CLI tool use DBus internally. > Fabio > > > > > > > > > > > > > > > > > > > > (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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > 真実はいつも一つ！/ Always, there's only one truth! > > > > > > > > > _______________________________________________ > > > > > > > > > devel mailing list -- devel@lists.fedoraproject.org > > > > > > > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > > > > > > 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@lists.fedoraproject.org > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > devel mailing list -- devel@lists.fedoraproject.org > > > > > > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > > > > > 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@lists.fedoraproject.org > > > > > > > > > > _______________________________________________devel mailing list -- > > > devel@lists.fedoraproject.org > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > 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@lists.fedoraproject.org > > > > _______________________________________________ > > > > devel mailing list -- devel@lists.fedoraproject.org > > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > > 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@lists.fedoraproject.org > > > > _______________________________________________devel mailing list -- > devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
