[Rpm-ecosystem] rpm-ostree's usage of libhif/hawkey merge

Honza Šilhan jsilhan at redhat.com
Thu Jan 28 10:10:12 UTC 2016


> From: "Neal Gompa" <ngompa13 at gmail.com>
> Honestly, at this point, I'm wondering why we don't just rename libhif
> to libdnf (or something else, but DNF would be the primary consumer).
> Now that the hawkey/hif merger is (mostly) complete and it's one
> library that was ultimately designed to be the foundations of both DNF
> and PackageKit frontends, I think it would make sense to call it
> libdnf from this point on. That would allow the hif backend to remain
> frozen at 0.2.0 and the new integrated code could be a new library.

I don't mind about renaming the library but I don't know if it would really
solve the problem. We bumped soname during the libhif/hawkey merge and the
stable API will be frozen in libhif-1.0.

> DNF would also eventually migrate from the hawkey python API to the
> libdnf gi based API in Python.

The hawkey API seems to be designed well, especially queries. We reuse generated
GI python bindings to reduce current Python bindings in C code. We would still
do a light layer to GI python bindings to stay compatible (and maybe still call
that layer python-hawkey)

> From: "Colin Walters" <walters at verbum.org>
> 
> See for example:
> https://github.com/rpm-software-management/libhif/pull/62#issuecomment-147811600
>
> There's also:
> 
> https://github.com/rpm-software-management/libhif/pull/69

If you have found a better approach in handling multiple connections then the change
should be within librepo. DNF would like to take advantage of it too.

we can discuss PRs at the meetings. libhif should be the base for DNF, PK and rpm-ostree.
Most of the demands from these package managers should be implemented in the libhif.
If rpm-ostree has extra requirements then we will find a way how to expose additional API.
When librepo will be part of libhif we will hide the details too so WRT PR 62 I would
expose librepo handlers and result with some deprecation warning that it will be removed
in the libhif-1.0 or next soname version.

> I have a concrete suggestion: what if we made libhif suitable for use as a
> git submodule
> for now (install to e.g. $libdir/rpm-ostree/libhif.so) ?  That way I can
> iterate quickly
> on API changes without blocking for a long time.  If I can't actually make
> use of a change
> I've submitted for weeks it just dramatically impacts iteration time.  I'd
> obviously keep sending patches
> upstream.

I am rather against submoduling. Everyone would have it's own version and that's
actually against the goal of hawkey/librepo/libhif merge. We had similar story
up until now where we worked independently on code refactoring and autotools to cmake
transition. We ended up with huge rebase where cmake didn't work and had to be reworked
again.


Honza


More information about the Rpm-ecosystem mailing list