[Rpm-ecosystem] DNF team would like to take over libdnf ownership
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:
>> 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:
>> 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.
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