[Rpm-ecosystem] DNF team would like to take over libdnf ownership

Neal Gompa ngompa13 at gmail.com
Mon Oct 30 23:48:32 UTC 2017

On Mon, Oct 30, 2017 at 3:32 PM, Daniel Mach <dmach at redhat.com> wrote:
> On Mon, Oct 30, 2017 at 2:02 PM, Colin Walters <walters at verbum.org> wrote:
>> On Mon, Oct 30, 2017, at 07:43 AM, Neal Gompa wrote:
>> > * Using C++ makes glib2 usage mostly pointless, as glib2 is by and
>> > large replaced by the C++ STL. The only advantage of GLib2 is GObject
>> > Introspection
>> Not quite; there's also the main event loop, which is also tied into
>> infrastructure like file monitoring (used today in libdnf to monitor
>> the rpmdb), and what are effectively "sub-libraries" in libglib
>> like GDBus.   For example today dnf talks to NM via pydbus:
>> https://github.com/rpm-software-management/dnf/blob/master/dnf/util.py#L261
>> which is currently synchronous, but any nontrivial usage
>> requires a main loop (which pydbus uses glib's most commonly).
>> And the whole "async" infrastructure in GTask is based on this.
>> Now, libdnf today is mostly synchronous, which is OK.  We could
>> keep it that way.
> Libdnf will most likely remain synchronous,
> but thanks for bringing this topic up.
> Making another note...

What prevents us from handling async things with libdnf?

>> In fact for various reasons we're highly likely at some point
>> in the future to change rpm-ostree to mostly use librpm/libdnf
>> from a subprocess.
>> One of those reasons is that librepo doesn't currently use any
>> of the GIO bits, notably GCancellable:
>> https://github.com/projectatomic/rpm-ostree/issues/897#issuecomment-318427563
>> This doesn't matter for a command line tool, but it matters a lot
>> for a daemon.  So by changing our libdnf to be in a subprocess we're
>> basically reworking the architecture to be daemon → internal command line.
>> But, even if we do this, we'll need to do things like have progress
>> on downloads be emitted via some internal messaging framework
>> (probably private DBus socket).  I think that'll be fine if things are
>> generally
>> synchronous in libdnf, but if we're talking about redoing libdnf
>> I think we need to keep these high level architectural bits in
>> mind and not just focus on the programming language.

If we're considering rearchitecting libdnf (albeit slowly), we should
consider making it so that things like rpm-ostree don't need to force
a subprocess model for asynchronous operations.

真実はいつも一つ!/ Always, there's only one truth!

More information about the Rpm-ecosystem mailing list