[Rpm-ecosystem] varlink for libdnf discussion

[Colin Walters]

Let's talk about https://github.com/varlink/documentation/wiki/Adding-varlink-to-DNF

It relates a lot to the libdnf efforts and higher level design.  And this discussion is also
probably generally interesting for other librpm-based systems like zypper, as those
also intersect with PackageKit today.

The whole topic of API for package management is a messy and complex one.
However, I've been thinking about varlink more, and I like the idea (although I confess
to not really having tried to really use or implement it in anger, so my opinion could change
after that =) )

The TL;DR of what I'm thinking here is to consider dropping the SWIG effort from libdnf, and focus
on varlink.  The question of implementation language (C/C++/whatever) then becomes
a lot more orthogonal as it's decoupled from how language bindings work.

In terms of varlink advantages: Some aspects of libdnf are dynamic/event-driven; I'm
specifically thinking here of package downloads for example.  That type of thing
is very natural and nice in a varlink-style system.  In contrast with C++ there's
no real standard for this - it's why both Qt and GObject have signals.

There are clear advantages in terms of robustness for forking off a separate process
for package management; librpm will directly call chroot() in-process which
is pretty hostile to anything else you have going on.  (rpm-ostree does not do this btw
for client-side layering today).

Further, the enormous size of Fedora metadata today causes lots of memory usage
in libsolv - this was one of the drivers behind having rpm-ostree do exit-on-idle:
https://github.com/projectatomic/rpm-ostree/pull/606
which works today, but it would have worked better from the start if the daemon
could just stay around and all of the heavy lifting was in a subprocess.

To repeat one of the varlink rationales; every programming language can speak JSON.
I suspect we don't need high performance in most cases - the only exception I can
think of offhand is say a `dnf search foo` type thing; but even then I suspect there
is a lot more things to optimize in searching over json parsing.

varlink doesn't apply to everything; to state the obvious, there's still a role
for shared libraries (and language bindings to them) and still a role for DBus, etc.
But specifically for package management I think varlink could make a lot of sense.