-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mon, 2017-10-30 at 11:48 +0100, Daniel Mach wrote: > 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. How is this going to work? Do we keep Hy* API around? What about DnfCmd and stuff like this? > 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. It was bad idea from the beginning. > > 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. I have HUGE doubts about this. > * DNF team to discuss any API changes with the stakeholders in timely > manner. I would say that each API/ABI change/breakage should follow with SONAME bump and should be mentioned in Pull Request. > * 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. Does it mean you will be wrapping std::vector and such to GPtrArray? Are you going to make some separate library for such conversions? Will you use glibmm? > > 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. That doesn't make any sense to me. > * 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 :) Note that it is already through GObject Introspection. > > 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/modularit > y > [3] https://github.com/rpm-software-management/libdnf/issues > [4] > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=li > bdnf > _______________________________________________ > Rpm-ecosystem mailing list > [email protected] > http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
- -- - -Igor Gnatenko -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAln3C18ACgkQaVcUvRu8 X0yG4Q/+Pp3DnzoTQ8YhfZw22mzw8TorzDQbTwsb39B+qZ3mw9lrKQdlyeQOd2fe XNyujq67x7WVUq8xrxCGFZ3PWaag1Zn9t9//mt1W2iVlq2dOhLeToCPlb1ls8YCy 7SWEFy7sklVHOBbUNiNdn9UBufhwd4D8MVCxW6w+GDAMyMu2WE2lAHJ0wISyzcKW h2zmN66LDZ0FQtygfZ7h7v6h2G27GmCQ3EuInOG0p47i/AxkHoq2l9bf/uFkfxrH OIUfXsYFAJbchKlLSGxzFZfNuESZRLWj8cSIp1DHkkSDBkGa0Ldz+heujlCjBKrb AvA59xinXYV1KdHBMXiYO8oneFxojkSGBH8vI26Qm5ko05b88HxM2RH53BHUGbFi HYkKgk9ejEMlyQwYvfRbXzdgh0wU38VX4bKooMVPy3YYaoAqNBt4I4T+0L9uNJh6 EOLXfOsX8RJc+5Hr6iLMJq7rLn4qeO1xsr68lHRDzoZyvMI95qPVLqYxM4/40PMq EwZTiLqkdZGdBnkLxlkD6MKQEcJ+Cn8GSE5GWDu2Zvd1W/7dL4Y/qtofUFC8B+f1 +cyH96z+gJpLTu9591ShaSVFCMHt4kPuL9H+nfewR/rnuZaKvUahl0v7Bb4udtY8 LrpGCJ376JCMe/vJl9ozYsamQ4tpJPIQovkPm7e4sog8LW2vbqs= =GyC9 -----END PGP SIGNATURE----- _______________________________________________ Rpm-ecosystem mailing list [email protected] http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
