Support comps

[cgwalters]

I think previously this was deemed somewhat ugly because libcomps is a non-glib library...should we consider folding it in directly into libhif and adding the glib dep? (Would the authors agree?)

But it's likely for rpm-ostree at least we'll need to support comps for https://mail.gnome.org/archives/ostree-list/2016-April/msg00020.html https://mail.gnome.org/archives/ostree-list/2016-April/msg00010.html

[hughsie]

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

[cgwalters]

https://github.com/rpm-software-management/libcomps/issues/22

[ignatenkobrain]

I think we should consider merging libcomps into libhif.

[Conan-Kudo]

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).

[jsilhan]

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

[cgwalters]

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

[Conan-Kudo]

@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.

[cgwalters]

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

[bam80]

Just wanted to clarify the status.

[Conan-Kudo]

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.

[j-mracek]

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.

[dmach]

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.

[j-mracek]

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.