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

[Daniel Mach]

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...


> 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.
>
>
> _______________________________________________
> Rpm-ecosystem mailing list
> Rpm-ecosystem at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-ecosystem/attachments/20171030/3512ab70/attachment.html>