[Rpm-ecosystem] DNF team would like to take over libdnf ownership

Daniel Mach dmach at redhat.com
Mon Oct 30 10:48:11 UTC 2017

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 remain
We're looking for your use cases.

More details follow:

We are getting requests to implement more features in microdnf,
such as modularity[1][2], unify repo cache and overall business logic.
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 customer
The code suffers with a technical debt, especially the libhif/hawkey merge
hasn't been finished.

>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.
* DNF team to discuss any API changes with the stakeholders in timely
* 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 re-use
existing C code without major changes.

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 existing
* Implement modularity[1]

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 :)

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[3] or
a bug[4].
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 users.
Please keep the discussion technical.


[1] https://docs.pagure.org/modularity/
[2] https://github.com/rpm-software-management/dnf/tree/wip/modularity
[3] https://github.com/rpm-software-management/libdnf/issues
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-ecosystem/attachments/20171030/cb583f81/attachment.html>

More information about the Rpm-ecosystem mailing list