Re: Semi-serious proposal: drop all optional entries from comps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux