Neal Gompa wrote: > This is where I think that transforming comps into metapackages would > probably solve the remaining issues we have with the current workflow.
I think metapackages could work for the distro composes, where ACL enforcement is wanted (so we would remove @group usage from kickstarts entirely and use the metapackages instead), but not for self-serve categorization of the average niche leaf package. The metapackage would not be open to all packagers (at most to provenpackagers), so it would just mean you would have to send a pull request to the metapackage rather than to fedora-comps. That would not really make things easier. You could use Supplements (reverse weak dependencies) to self-serve-add your package to the metapackage, but I am not sure that we would want such widespread use of Supplements. Another issue if you want to use metapackages for categorization is that UIs such as Dnfdragora, or whatever tool converts the metapackages to a representation those UIs will consume, would have to be told what packages are such categorization metapackages. Out of the box, they would just be packages like any other, not browsable in UIs. The switch from @group to metapackages for kickstarts would also make things worse in some ways though. E.g., it is currently possible to pick a group minus one or two packages: @group -groupmember1 -groupmember2 If you use Requires in the metapackage, the kickstart has no way to do that at all. If you use Recommends in the metapackage (or Supplements in the individual package), the kickstart can do the above, but any update the user does will drag the excluded group members back in (because of https://github.com/openSUSE/libsolv/issues/168 , which libsolv upstream refuses to fix), which is also clearly not what we want. So the only workaround would be to ignore the metapackage and list every wanted package explicitly, which makes me wonder why we would carry the metapackage at all. So to keep this working with metapackages, somebody would have to address libsolv issue 168. I think that, if spin composes are the only things comps would still be used for and if tools like Dnfdragora were moved to something different (such as resurrected RPM Group tags), then we should actually consider inlining the comps groups into the spin kickstarts (for common parts across several spins, a kickstart include can be used, this is already done in several places of fedora-kickstarts). I think having the kickstart contents configured in a single place (fedora-kickstarts) rather than two (fedora-kickstarts and fedora-comps) would be an improvement. If no user of comps were left, we could then drop comps entirely, but do not forget that it is currently used by Dnfdragora and also by the traditional (non-live) installer modes of Anaconda. As for metapackages, I think they cause more problems than they solve, at least in the current state of our tooling, as detailed above. Kevin Kofler _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
