[Rpm-ecosystem] varlink for libdnf discussion
walters at verbum.org
Wed May 2 17:21:50 UTC 2018
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:
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.
More information about the Rpm-ecosystem