[Rpm-ecosystem] libhif, and grand plans

Richard Hughes hughsient at gmail.com
Tue Jun 30 08:33:30 UTC 2015

On 30 June 2015 at 04:52, Neal Gompa <ngompa13 at gmail.com> wrote:
> Sorry, I didn't mean to write "we", but I am looking to use hawkey for
> something without librepo, as it's not for rpm-md repos. That said, the
> point is that I don't see a strong case to remove the modularity that was
> just introduced.

I see an exceptionally strong case: things keep breaking. We've had 3
instances in the last 18 months where Fedora updates stop working
because either librepo or hawkey changed behaviour in a subtle way
which broke assumptions in the stack above. That's 3 times we've had
to ask people to run a specific low-level command to fix their system
as we couldn't ship an automated update to fix the broken update.

Also, because librepo, hawkey and libhif release at different times we
have to test all combinations of old and new, upgrading a first, then
b, and also a+b at the same time, sometimes jumping two minor
versions. The QA matrix is simply crazy for three small essential
libraries that do actually very little.

The other reason is clarity. What do we tell people when they ask "how
do I download a package in C"? What about Python? What about
Javascript? With a simple GObjectIntrospection interface we can tell
people one way to do something rather than the long convoluted answer
we currently have.

The fact that the library is larger than they might need is no issue;
merging the libraries actually saves space as you don't need to do
three sets of linker invocations, and you have a smaller surface for
testing. I'm totally for exposing more API in libhif for people to
use, even it's just a 1:1 wrapper for the depsolver underneath. I also
don't buy the argument put forward by some people that the GObject dep
is too large as it's basically impossible to build a system without
glib these days.

What we do need to do is show the few people brave enough to be riding
the wave how to port to libhif away from the lower libraries, which
will mean writing some tutorials and sample code. The current stack
isn't maintainable and isn't working. It's too complicated and has too
many interconnected parts. Just looking at conversion functions like
you can see what we have now is a mess and needs cleaning up.


More information about the Rpm-ecosystem mailing list