> From: "Neal Gompa" <ngomp...@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" <walt...@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 _______________________________________________ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
