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

Colin Walters walters at verbum.org
Mon Oct 30 13:02:37 UTC 2017


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.

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.




More information about the Rpm-ecosystem mailing list