Support comps about libdnf HOT 13 CLOSED

This is definitely going to be supported as part of the dnf5 work. @dmach or @j-mracek would have a better idea of when that will land.

from libdnf.

I am not 100 % sure what exactly is requested.
dnf5 work means to move a lot of functionality from dnf to libdnf including support of comps, and adding of query functionality for comps. Due to our limitation we cannot reimplement libcomps in libdnf. May be in far far future. dnf5 will be written in C++ and we will provide bindings for c, python and so on. We have no plan to support glib macros, therefore glib auto-free functions will require to provide a destructor for proper functionality.

from libdnf.

I'm really not keen on the design of libcomps at all. I'm totally for porting and folding into libhif.

from libdnf.

rpm-software-management/libcomps#22

from libdnf.

I think we should consider merging libcomps into libhif.

from libdnf.

I'm all for having the comps functionality as part of libhif, but I think we would probably need some sort of Comps Python interface preserved for portability (like we've done for the legacy hawkey Python bindings).

from libdnf.

I am for merging libcomps although at first we should merge librepo. Isn't libsolv comps support just enough for rpm-ostree purposes?

from libdnf.

I was totally unaware libsolv had comps support. I'll look at that.

from libdnf.

@cgwalters According to @mlschroe, it's somewhat rudimentary (though I forget exactly what the limits of the built-in comps support are). As of libsolv 0.6.20 in Fedora, the comps support is enabled. Extending libsolv's comps support (as needed) and using that in libhif is probably a much more solid path.

from libdnf.

https://bugzilla.redhat.com/show_bug.cgi?id=1340556

from libdnf.

Just wanted to clarify the status.

from libdnf.

Let me clarify - the new libdnf major version (currently dnf-5-devel branch) will support working with comps groups. It's going to use libcomps as a backend for reading comps information, but the libcomps internals will not be exposed, only a high-level libdnf API will.
No glib support is planned as we're moving libdnf away from glib to C++17.

from libdnf.

I have a good news - comps support was implementd in DNF5 (available in Fedora38) project. We do not have a plan to extent the LIBDNF functionality, therefore it will be replaced by DNF5 (Fedora 39). I am closing the issue.

from libdnf.