[Rpm-ecosystem] DNF team would like to take over libdnf ownership
dmach at redhat.com
Mon Oct 30 19:32:59 UTC 2017
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:
> 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...
> 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:
> 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
> 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.
> Rpm-ecosystem mailing list
> Rpm-ecosystem at lists.rpm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rpm-ecosystem