[Rpm-ecosystem] DNF team would like to take over libdnf ownership
dmach at redhat.com
Mon Oct 30 10:48:11 UTC 2017
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, 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.
* Merge DNF Base class with libdnf's context.
* Re-shuffle existing C code into new structures, but still keep existing
* Implement modularity
* 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 or
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rpm-ecosystem