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

[Daniel Mach]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-ecosystem/attachments/20171030/cb583f81/attachment.html>