-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support comps #107
Comments
I'm really not keen on the design of libcomps at all. I'm totally for porting and folding into libhif. |
I think we should consider merging libcomps into libhif. |
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). |
I am for merging libcomps although at first we should merge librepo. Isn't libsolv comps support just enough for rpm-ostree purposes? |
I was totally unaware libsolv had comps support. I'll look at that. |
@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. |
There's a request from fedora releng to support parsing comps groups for rpm-ostree, this is a RFC/WIP patch for it. I think the main architectural questions are: - Use @ like yum to denote group names? - Add them to the depsolver, but do not return them to the rest of the architecture. This may make it harder to port dnf, since I think it currently has persistent groups enabled? Related: rpm-software-management#107
Just wanted to clarify the status. |
I am not 100 % sure what exactly is requested. |
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. |
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. |
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
The text was updated successfully, but these errors were encountered: