<div dir="ltr"><div><div>Hi everyone,<br>My name is Daniel Mach and I'm leading the DNF team.<br><br><br>TL;DR:<br><br>The DNF team wants to take libdnf over and re-start development, which would<br>possibly include using C++ (only to limited and reasonable extent). The goal<br>is to get existing DNF code into libdnf. The current APIs would remain intact.<br>We're looking for your use cases.<br><br><br>More details follow:<br><br>We are getting requests to implement more features in microdnf,<br>such as modularity[1][2], unify repo cache and overall business logic.<br>Porting big portions of existing DNF code (Python) into a C library<br>seems to be the only feasible option to avoid code duplication.<br><br>In the first place, we'd like to clarify libdnf ownership and responsibilities.<br>Libdnf is currently co-maintained by several teams (DNF, PackageKit,<br>rpm-ostree), which makes it an unmaintained orphan.<br>There are gaps in roadmap, development and response time to the customer issues.<br>The code suffers with a technical debt, especially the libhif/hawkey merge<br>hasn't been finished.<br><br>From organizational perspective, we are proposing following:<br>* DNF team to own libdnf and be fully responsible for it.<br>* DNF team to guarantee existing C and Python APIs.<br>* DNF team to discuss any API changes with the stakeholders in timely manner.<br>* PackageKit to become a libdnf stakeholder.<br>* rpm-ostree to become a libdnf stakeholder.<br><br>We are looking for a way how to boost the development speed by using a more<br>high-level programming language than C. We are considering C++ at the moment,<br>because it offers some features we (mainly Python programmers) would appreciate,<br>including strongly typed lists and dictionaries, less work with pointers and<br>last, but not least - native objects. It also allows us to wrap and re-use<br>existing C code without major changes.<br><br>Short-term plan: Fix libdnf technical debt<br>* Finish libhif and hawkey merge.<br>* Remove unused code.<br>* Fix code duplicates.<br>* Hide private functions which were published by mistake.<br><br>Mid-term plan:<br>* Merge DNF Base class with libdnf's context.<br>* Re-shuffle existing C code into new structures, but still keep existing APIs.<br>* Implement modularity[1]<br><br>Long-term plan:<br>* Full rewrite/cleanup<br>* Move major part of DNF's code into libdnf<br>* New, well-defined, fully supported API<br><br>The Holy Grail:<br>* libdnf becomes "The Software Management Library"<br>* libdnf has fully documented and tested API<br>* libdnf has bindings to infinite amount of languages :)<br><br>I'd like to ask you for your feedback on the plan.<br>If you have any use cases you'd like implemented, please open an issue[3] or<br>a bug[4].<br>I understand that the C++ part sounds controversial, but as long as we keep the<br>C API available and intact, nothing should change for the existing users.<br>Please keep the discussion technical.<br></div><div><br></div><div><br></div>thanks,<br></div>Daniel<br><div><div><br><br>[1] <a href="https://docs.pagure.org/modularity/">https://docs.pagure.org/modularity/</a><br>[2] <a href="https://github.com/rpm-software-management/dnf/tree/wip/modularity">https://github.com/rpm-software-management/dnf/tree/wip/modularity</a><br>[3] <a href="https://github.com/rpm-software-management/libdnf/issues">https://github.com/rpm-software-management/libdnf/issues</a><br>[4] <a href="https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=libdnf">https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=libdnf</a><br><br></div></div></div>