Hi everyone, My name is Daniel Mach and I'm leading the DNF team.
TL;DR: 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 intact. 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 responsibilities. 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 issues. 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 manner. * 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 moment, because it offers some features we (mainly Python programmers) would appreciate, 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 APIs. * 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 the C API available and intact, nothing should change for the existing users. Please keep the discussion technical. thanks, Daniel [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 [4] https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=libdnf
_______________________________________________ Rpm-ecosystem mailing list [email protected] http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
