[Rpm-ecosystem] [rpm-software-management] LIBDNF - gobject-introspection and reduction of public functions

Neal Gompa ngompa13 at gmail.com
Fri Nov 17 14:23:50 UTC 2017


On Thu, Nov 16, 2017 at 5:14 AM, Igor Gnatenko
<ignatenkobrain at fedoraproject.org> wrote:
> On Thu, 2017-11-16 at 11:08 +0100, Jaroslav Mracek wrote:
>> Dear supporters of LIBDNF,
>
> You sent to wrong mailing list, replying to proper one here.
>>
>> According to a long term plan for LIBDNF, we would like to make LIBDNF
>> lighter, with supported API. At the beginning we would like to drop a
>> support of any externally unused functionality or bindings. At the present
>> time, LIBDNF provides bindings using  gobject-introspection for
>> dnf-context.cpp, dnf-context.h, dnf-repo.cpp dnf-repo.h, dnf-state.h,
>> dnf-state.cpp, and dnf-version.h, but there is not known anybody that use
>> it. I would like to open a discussion if there is any reason to support
>> those bindings for now, because they reduce our flexibility in further
>> development.
>>
>> Additionally I started with reduction of publicly available functions (
>> https://github.com/rpm-software-management/libdnf/pull/367) to reduce
>> maintenance cost and to open a door for further changes without risk of
>> changing API. The pull-request represents only the first part and it
>> contains only utils that are only internally used by LIBDNF but unused by
>> PackageKit, rpm-ostree, or microdnf. Please If any suggestions or issues
>> with that, please let us know.
>>

So currently, there's no one I know of using the GIR bindings except
for DNF itself for SWDB. However, one of the strategies being
considered for migrating Mageia's tooling to the DNF stack is to use
the gobject-introspection bindings because most of the tools are in
Perl. Unless we go down the road of using Inline::Python to use the
DNF Python 3 API in our tools, I think we'd probably want to use the
GObject Introspection bindings. I was hoping that more of the Python
API would become available through g-i...

Angelo Naselli (CC'd here) is helping me figure out our porting effort
(and the primary developer of dnfdragora), and Thierry Vignaud (also
CC'd here) is the developer/maintainer of our installer and the media
creation tools. Both of these people would have a good idea of how we
want to proceed.


-- 
真実はいつも一つ!/ Always, there's only one truth!


More information about the Rpm-ecosystem mailing list