[Rpm-ecosystem] DNF team would like to take over libdnf ownership
ignatenkobrain at fedoraproject.org
Mon Oct 30 11:22:07 UTC 2017
-----BEGIN PGP SIGNED MESSAGE-----
On Mon, 2017-10-30 at 11:48 +0100, Daniel Mach wrote:
> Hi everyone,
> My name is Daniel Mach and I'm leading the DNF team.
> The DNF team wants to take libdnf over and re-start development,
> which would
> possibly include using C++ (only to limited and reasonable extent).
> The goal
> is to get existing DNF code into libdnf. The current APIs would
How is this going to work? Do we keep Hy* API around? What about DnfCmd
and stuff like this?
> We're looking for your use cases.
> More details follow:
> We are getting requests to implement more features in microdnf,
> such as modularity, unify repo cache and overall business
> Porting big portions of existing DNF code (Python) into a C library
> seems to be the only feasible option to avoid code duplication.
> In the first place, we'd like to clarify libdnf ownership and
> Libdnf is currently co-maintained by several teams (DNF, PackageKit,
> rpm-ostree), which makes it an unmaintained orphan.
> There are gaps in roadmap, development and response time to the
> The code suffers with a technical debt, especially the libhif/hawkey
> hasn't been finished.
It was bad idea from the beginning.
> From organizational perspective, we are proposing following:
> * DNF team to own libdnf and be fully responsible for it.
> * DNF team to guarantee existing C and Python APIs.
I have HUGE doubts about this.
> * DNF team to discuss any API changes with the stakeholders in timely
I would say that each API/ABI change/breakage should follow with SONAME
bump and should be mentioned in Pull Request.
> * PackageKit to become a libdnf stakeholder.
> * rpm-ostree to become a libdnf stakeholder.
> We are looking for a way how to boost the development speed by using
> a more
> high-level programming language than C. We are considering C++ at the
> because it offers some features we (mainly Python programmers) would
> including strongly typed lists and dictionaries, less work with
> pointers and
> last, but not least - native objects. It also allows us to wrap and
> existing C code without major changes.
Does it mean you will be wrapping std::vector and such to GPtrArray?
Are you going to make some separate library for such conversions? Will
you use glibmm?
> Short-term plan: Fix libdnf technical debt
> * Finish libhif and hawkey merge.
> * Remove unused code.
> * Fix code duplicates.
> * Hide private functions which were published by mistake.
> Mid-term plan:
> * Merge DNF Base class with libdnf's context.
> * Re-shuffle existing C code into new structures, but still keep
That doesn't make any sense to me.
> * Implement modularity
> Long-term plan:
> * Full rewrite/cleanup
> * Move major part of DNF's code into libdnf
> * New, well-defined, fully supported API
> The Holy Grail:
> * libdnf becomes "The Software Management Library"
> * libdnf has fully documented and tested API
> * libdnf has bindings to infinite amount of languages :)
Note that it is already through GObject Introspection.
> I'd like to ask you for your feedback on the plan.
> If you have any use cases you'd like implemented, please open an
> issue or
> a bug.
> I understand that the C++ part sounds controversial, but as long as
> we keep
> C API available and intact, nothing should change for the existing
> Please keep the discussion technical.
>  https://docs.pagure.org/modularity/
>  https://github.com/rpm-software-management/dnf/tree/wip/modularit
>  https://github.com/rpm-software-management/libdnf/issues
> Rpm-ecosystem mailing list
> Rpm-ecosystem at lists.rpm.org
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the Rpm-ecosystem