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